This is an archive of the discontinued LLVM Phabricator instance.

Added -mlink-init-bitcode-file option to pre-populate new module with IR loaded from specified file.
AbandonedPublic

Authored by tra on May 12 2015, 2:30 PM.

Details

Summary
  • Added -mlink-init-bitcode-file option to pre-populate new module with IR loaded from specified file.
  • Accept IR assembly as well as bitcode.
  • Added test case.

The change is needed for upcoming CUDA-related changes that require linking with large device-specific library provided as bitcode. Initializing module with the library IR is faster than linking the library in after compilation. It also allows convenient way to run some cuda-specific passes on the library IR (NVVM reflect and Internalize) alone without affecting IR we generate during compilation.

Diff Detail

Event Timeline

tra updated this revision to Diff 25628.May 12 2015, 2:30 PM
tra retitled this revision from to Added -mlink-init-bitcode-file option to pre-populate new module with IR loaded from specified file..
tra updated this object.
tra edited the test plan for this revision. (Show Details)
tra added reviewers: echristo, dblaikie, rnk.
tra added a subscriber: Unknown Object (MLST).
echristo edited edge metadata.May 26 2015, 2:55 PM

Is there any reason not to purpose the existing option for this?

Maybe do some archaeology to find out who added it and ask if it's fine to make it just start with the module?

-eric

pcc added a subscriber: pcc.Jun 8 2015, 3:23 PM

I was the person who originally introduced this flag in r143314. As I recall this flag was introduced in order to support linking a bitcode module containing an implementation of a runtime library for a GPU (e.g. libclc).

The reason I made the flag link the bitcode after compilation was that I wanted to avoid breaking any invariants that Clang's code generator might have (e.g. if both the bitcode file and the C source file define a weak symbol, Clang's IR generator may get confused by the presence of a duplicate symbol, whereas the IR linker already knows to discard one of them). If avoiding the IR linker provides a significant performance advantage, it does seem reasonable to make -mlink-bitcode-file pre-populate the module, and start fixing any assumptions we're currently making in the IR generator.

Cool. I think that's probably how we should go.

Thanks!

-eric

tra added a comment.Jun 8 2015, 4:20 PM
In D9721#185342, @pcc wrote:

The reason I made the flag link the bitcode after compilation was that I wanted to avoid breaking any invariants that Clang's code generator might have (e.g. if both the bitcode file and the C source file define a weak symbol, Clang's IR generator may get confused by the presence of a duplicate symbol, whereas the IR linker already knows to discard one of them). If avoiding the IR linker provides a significant performance advantage, it does seem reasonable to make -mlink-bitcode-file pre-populate the module, and start fixing any assumptions we're currently making in the IR generator.

Thanks, Peter. Weak symbols indeed do not work with this patch -- compiler complains about two definitions with the same mangled name.
Time for plan C...

tra abandoned this revision.Jun 9 2015, 1:05 PM

Plan C: I'll reuse existing -mlink-bitcode-file.

Sounds good. :)

-eric