llvm dev - Jan 2013 - [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>

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

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

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
>