[llvm-commits] pr11367

Matt Pharr matt.pharr at gmail.com
Wed Nov 16 08:13:18 PST 2011


On Nov 15, 2011, at 9:45 AM, Chris Lattner wrote:
> On Nov 14, 2011, at 11:24 AM, Matt Pharr wrote:
> 
>> It's not a completely theoretical use case: the ispc compiler depended on the old behavior from LinkModules() ("link everything in the provided modules together, and don't be clever about skipping stuff that seems to not be used"), and the lazy linking change broke that.
> 
> Why?  Can you explain the use case?

The basic context is that the front-end needs to emit code for things like "do a masked store of this value to this location with this mask", where the implementation of that thing is target-dependent.  e.g. for masked store, for a target like AVX, this can be a single instruction, whereas for SSE a more complex instruction sequence is needed.

Previously, this had been implemented by linking a number of precompiled target-specific modules together at compile time, based on the selected target, before compiling the user's code.  The compiler could then emit calls to those functions as needed.

All of those functions had been defined as internal/alwaysinline, so that by the time optimization was done, they'd be inlined and the original stand-alone definitions would go away in the final compiler output.  So the LinkModules() change broke this, since it didn't bring in all of those functions during the initial module linking step.

(I realize that I could just add declarations for those functions to the module before compiling the user's program and then link in the definitions at the end and things would just work--I'm just explaining how it was implemented.)

I ended up working around the LinkModules() change by removing the internal qualifiers and then adding a pass that has a list of these functions that then changes them to be internal after they've been linked in.  This is obviously clunky.

I hope this gives some useful context.

Thanks,
-matt





More information about the llvm-commits mailing list