[LLVMdev] RFC: Replacing publicly accessible class IDs with getters

陳韋任 (Wei-Ren Chen) chenwj at iis.sinica.edu.tw
Mon Feb 4 18:41:48 PST 2013


On Mon, Feb 04, 2013 at 08:06:46AM -0600, Matthew Curtis wrote:
> 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'.

  Understood. Maybe you can submit patch to llvm-commits to get more
attention, or ping someone who maintains this things.

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




More information about the llvm-dev mailing list