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

[Andrew Trick]

On Mar 5, 2013, at 11:30 AM, Matthew Curtis <mcurtis at codeaurora.org> wrote:

> 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.


Sorry, I don't really understand the nature of the linker bug. I don't understand how it's possible for Polly to import llvm's C++ ABI if it can't "import data". Are you trying to make a DLL-safe subset of llvm's C++ ABI, free of all global data and static fields? That doesn't seem generally possible without formalizing that interface. It's something you should discuss on llvm-dev with people who have experience with that sort of thing!

-Andy