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

Robinson, Paul Paul.Robinson at am.sony.com
Tue Mar 5 14:50:59 PST 2013



> -----Original Message-----
> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-
> bounces at cs.uiuc.edu] On Behalf Of Andrew Trick
> Sent: Tuesday, March 05, 2013 1:47 PM
> To: Matthew Curtis
> Cc: tobias at grosser.es; llvm-commits at cs.uiuc.edu; Sebastian Pop
> Subject: Re: [PATCH] Add getters for Pass IDs used by Polly plug-in.
> 
> 
> 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

Based on the problem description and the fix, it would have to be that:
- function definitions in different DLLs are resolved to one instance, but
- data-item definitions in different DLLs are NOT resolved to one instance.

I could see that behavior cropping up if the function definitions were
dll-exported but the data definitions were not.
Otherwise it seems like a particularly weird Windows bug.
I've been away from Windows too long to comment any further.
--paulr






More information about the llvm-commits mailing list