[LLVMdev] RFC: Replacing publicly accessible class IDs with getters
Matthew Curtis
mcurtis at codeaurora.org
Mon Feb 4 06:06:46 PST 2013
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
More information about the llvm-dev
mailing list