[PATCH] Add getters for Pass IDs used by Polly plug-in.

[Matthew Curtis]

On 3/5/2013 1:03 PM, Andrew Trick wrote:
> On Mar 4, 2013, at 2:40 PM, Matthew Curtis <mcurtis at codeaurora.org> wrote:
>
>> [re-submitting this patch in the hopes that it will find new life]
>>
>> This patch helps resolve a couple of issues we encountered while
>> porting the Polly plug-in to Windows.
>>
>> The Polly plugin depends on some LLVM Passes which it identifies via
>> Pass IDs. Pass IDs are implemented as the address of a static member
>> variable (ID) of the Pass. On Windows however, there seems to be a bug
>> in the Visual Studio compiler or linker that results in multiple
>> dll-local copies of this data when referenced directly. The result is
>> that Polly is unable to locate Passes that are part of the executable
>> it is being loaded into.
>>
>> As a work around, this patch adds getters (GetClassPassID) for the
>> Pass IDs used by Polly. The symbols for the globals are not
>> exported. The getters are exported and Polly uses them instead.
>>
>> Removing use of global data by the Polly plug-in also makes it
>> possible to delay load LLVM symbols from the containing executable
>> which in turn removes the restriction that the executable have a
>> specific name (determined at link-time).
>>
>> We also considered a couple alternatives to this minimal patch:
>>
>> 1) Update *all* Passes to provide GetClassPassID in lieu of ID.
>>
>>    This leaves the code in the cleanest state and would be a good
>>    choice if starting from scratch. However I started implementing it
>>    and it turns out to have a very large ripple effect. Not only does
>>    it require changing a large number of files in LLVM, but it breaks
>>    source compatibility for passes that are not part of the LLVM
>>    source.
>>
>>    That being said, I'd be willing to do the work if everyone thinks
>>    that's the right thing to do and we're willing break source
>>    compatibility.
>>
>>    Perhaps we could ease the pain by deprecating ID for some time
>>    before removing it.
>>
>> 2) Add GetClassPassID to Passes accessible by plug-ins (i.e. those
>>    under include/llvm), but leave ID as it is.
>>
>>    As with the proposed patch, this may cause confusion because there
>>    are multiple ways of getting a Pass's ID. But at least it's not
>>    specific to the Polly plug-in and other plug-ins on Windows may
>>    benefit.
>>
>> Thanks,
>> Matthew Curtis
>>
>> BTW, there's a brief related discussion on llvm-dev here:
>> http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/058838.html
>> http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-February/thread.html#58982
> Hi Matthew,
>
> Isn't it more convenient to refer to pass IDs without including all the pass headers and being forced to define the pass in the header?
Yes, but pass IDs are not always provided separately. For example the 
DominatorTree, LoopInfo, and ScalarEvolution passes do not.
>   Does the linker resolve the ID address uniquely when you use an extern global reference instead?
No. It does not work correctly when data is shared across library 
boundaries.
>   This is the current style for pass IDs:
>
> .h:
> extern char &MyPassID;
>
> .cpp:
> MyPass : FunctionPass {
>    static ID;
> };
>
> char &MyPassID = MyPass::ID;
>
> It seems awkward to use a reference vs ptr, but I guess it was done for migration from the old style.
>
> I would prefer to have one standard for identifying passes. "extern char *PassID"  seems ideal. If everyone agrees and it works in all situations, we could just migrate to that.
I certainly agree that ideally there should be a single standard. To 
accomodate Windows plug-ins it would have to be "char *GetPassID()", or 
better yet "const void* GetPassID()".

My biggest concern in removing the existing mechanism is the impact it 
would have to existing plugins or passes that are not part of the LLVM 
codebase.

>
> -Andy
Thanks for the response!

Matthew Curtis

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation