Matthew Curtis
2013-Jan-30 18:02 UTC
[LLVMdev] RFC: Replacing publicly accessible class IDs with getters
Hello all, In the process of porting the Polly plug-in to Windows we encountered a couple of issues stemming from the use (within Polly) of global data from LLVM. By far the most common occurrence of this is the definition by a class of a publicly accessible static ID, the address of which is used to uniquely identify the class. For example class AliasAnalysis { public: static char ID; // Class identification, replacement for typeinfo }; This turns out to be problematic on Windows for two reasons: 1) We found that Visual Studio actually defines two copies of the ID, one within the clang executable and another within the Polly library. This results in Polly being unable to identify LLVM passes. (This seems like a bug in Visual Studio, but we could not find a resolution other than changing LLVM as noted below). 2) We chose to use delay loading for symbols imported by Polly from clang. This allows the Polly dll to be loaded into any executable that provides the required symbols. However delay loading precludes the importing of data[1]. We would like to resolve these issues by replacing public access of the ID with a getter: class AliasAnalysis { private: static char ID; // Class identification, replacement for typeinfo public: static const void *getClassPassID(); }; Thoughts? Matthew Curtis [1] http://msdn.microsoft.com/en-us/library/yx1x886y.aspx -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130130/20e16ebd/attachment.html>
陳韋任 (Wei-Ren Chen)
2013-Feb-01 03:07 UTC
[LLVMdev] RFC: Replacing publicly accessible class IDs with getters
On Wed, Jan 30, 2013 at 12:02:47PM -0600, Matthew Curtis wrote:> Hello all, > > In the process of porting the Polly plug-in to Windows we encountered a couple > of issues stemming from the use (within Polly) of global data from LLVM. > > By far the most common occurrence of this is the definition by a class of a > publicly accessible static ID, the address of which is used to uniquely > identify the class. For example > > class AliasAnalysis { > > public: > static char ID; // Class identification, replacement for typeinfo > > }; > > > This turns out to be problematic on Windows for two reasons: > > 1) We found that Visual Studio actually defines two copies of the ID, one > within the clang executable and another within the Polly library. This results > in Polly being unable to identify LLVM passes. (This seems like a bug in Visual > Studio, but we could not find a resolution other than changing LLVM as noted > below). > 2) We chose to use delay loading for symbols imported by Polly from clang. This > allows the Polly dll to be loaded into any executable that provides the > required symbols. However delay loading precludes the importing of data[1]. > > We would like to resolve these issues by replacing public access of the ID with > a getter: > > class AliasAnalysis { > > private: > static char ID; // Class identification, replacement for typeinfo > > public: > static const void *getClassPassID(); > };I think that would be O.K., but why getClassPassID return "const void *" not just "char"? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Matthew Curtis
2013-Feb-04 14:06 UTC
[LLVMdev] RFC: Replacing publicly accessible class IDs with getters
On 1/31/2013 9:07 PM, 陳韋任 (Wei-Ren Chen) wrote:> On Wed, Jan 30, 2013 at 12:02:47PM -0600, Matthew Curtis wrote: >> Hello all, >> >> In the process of porting the Polly plug-in to Windows we encountered a couple >> of issues stemming from the use (within Polly) of global data from LLVM. >> >> By far the most common occurrence of this is the definition by a class of a >> publicly accessible static ID, the address of which is used to uniquely >> identify the class. For example >> >> class AliasAnalysis { >> >> public: >> static char ID; // Class identification, replacement for typeinfo >> >> }; >> >> >> This turns out to be problematic on Windows for two reasons: >> >> 1) We found that Visual Studio actually defines two copies of the ID, one >> within the clang executable and another within the Polly library. This results >> in Polly being unable to identify LLVM passes. (This seems like a bug in Visual >> Studio, but we could not find a resolution other than changing LLVM as noted >> below). >> 2) We chose to use delay loading for symbols imported by Polly from clang. This >> allows the Polly dll to be loaded into any executable that provides the >> required symbols. However delay loading precludes the importing of data[1]. >> >> We would like to resolve these issues by replacing public access of the ID with >> a getter: >> >> class AliasAnalysis { >> >> private: >> static char ID; // Class identification, replacement for typeinfo >> >> public: >> static const void *getClassPassID(); >> }; > I think that would be O.K., but why getClassPassID return "const void > *" not just "char"?The class is actually identified by the address of 'ID'. The value of 'ID' is irrelevant. So where it is currently used you will amost always find '&ClassName::ID'.> Regards, > chenwj >-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Duncan Sands
2013-Feb-05 14:47 UTC
[LLVMdev] RFC: Replacing publicly accessible class IDs with getters
Hi Matthew,> In the process of porting the Polly plug-in to Windows we encountered a couple > of issues stemming from the use (within Polly) of global data from LLVM. > > By far the most common occurrence of this is the definition by a class of a > publicly accessible static ID, the address of which is used to uniquely identify > the class. For example > > class AliasAnalysis { > > public: > static char ID; // Class identification, replacement for typeinfo > > }; > > > This turns out to be problematic on Windows for two reasons: > > 1) We found that Visual Studio actually defines two copies of the ID, one within > the clang executable and another within the Polly library. This results in Polly > being unable to identify LLVM passes. (This seems like a bug in Visual Studio, > but we could not find a resolution other than changing LLVM as noted below).this sounds like the kind of thing you get on linux if both clang and polly are linked with the same LLVM libraries. Are you sure it isn't something analogous on windows?> 2) We chose to use delay loading for symbols imported by Polly from clang. This > allows the Polly dll to be loaded into any executable that provides the required > symbols. However delay loading precludes the importing of data[1]. > > We would like to resolve these issues by replacing public access of the ID with > a getter: > > class AliasAnalysis { > > private: > static char ID; // Class identification, replacement for typeinfo > > public: > static const void *getClassPassID(); > };That said, this looks pretty reasonable to me. Ciao, Duncan.> > > Thoughts? > > Matthew Curtis > > [1] http://msdn.microsoft.com/en-us/library/yx1x886y.aspx > > > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Apparently Analagous Threads
- [LLVMdev] RFC: Replacing publicly accessible class IDs with getters
- [LLVMdev] RFC: Replacing publicly accessible class IDs with getters
- [LLVMdev] RFC: Replacing publicly accessible class IDs with getters
- Good practice for naming classes, builders, attributes, getters/setters for object composition
- Getters and setters problem?