Commit Graph

10 Commits

Author SHA1 Message Date
Rafael Espindola 4b5ec26373 Switch the linker to having a whitelist of GVs.
This replaces DoNotLinkFromSource with ValuesToLink. It also moves the
computation of ValuesToLink earlier.

It is a bit simpler and an important step in slitting the linker into an
ir mover and a linker proper.

The test change is because we now avoid creating dead declarations.

llvm-svn: 254559
2015-12-02 22:59:04 +00:00
Rafael Espindola 8c04472edf Delete what is now duplicated code.
Having to import an alias as declaration is not thinlto specific.

The test difference are because when we already have a decl and we are
not importing it, we just leave the decl alone.

llvm-svn: 254556
2015-12-02 22:22:24 +00:00
Rafael Espindola 8934577171 Disallow aliases to available_externally.
They are as much trouble as aliases to declarations. They are requiring
the code generator to define a symbol with the same value as another
symbol, but the second symbol is undefined.

If representing this is important for some optimization, we could add
support for available_externally aliases. They would be *required* to
point to a declaration (or available_externally definition).

llvm-svn: 254170
2015-11-26 19:22:59 +00:00
Teresa Johnson 6290dbc0f7 [ThinLTO] Handle bitcode without function summary sections gracefully
Summary:
Several fixes to the handling of bitcode files without function summary
sections so that they are skipped during ThinLTO processing in llvm-lto
and the gold plugin when appropriate instead of aborting.

1 Don't assert when trying to add a FunctionInfo that doesn't have
  a summary attached.
2 Skip FunctionInfo structures that don't have attached function summary
  sections when trying to create the combined function summary.
3 In both llvm-lto and gold-plugin, check whether a bitcode file has
  a function summary section before trying to parse the index, and skip
  the bitcode file if it does not.
4 Fix hasFunctionSummaryInMemBuffer in BitcodeReader, which had a bug
  where we returned to early while looking for the summary section.

Also added llvm-lto and gold-plugin based tests for cases where we
don't have function summaries in the bitcode file. I verified that
either the first couple fixes described above are enough to avoid the
crashes, or fixes 1,3,4. But have combined them all here for added
robustness.

Reviewers: joker.eph

Subscribers: llvm-commits, joker.eph

Differential Revision: http://reviews.llvm.org/D14903

llvm-svn: 253796
2015-11-21 21:55:48 +00:00
Teresa Johnson ba5d68dfff [ThinLTO] Update test to be more tolerant of ordering changes
Update the ThinLTO function importing test to use DAG forms of checks so
that it is more tolerant of changes to relative ordering between
imported decls/defs. This reduces the number of changes required by the
comdat importing patch I am sending for review shortly.

llvm-svn: 252932
2015-11-12 19:31:46 +00:00
Teresa Johnson 3cd8161c9b [ThinLTO] WeakAny fixes/cleanup
Ensure WeakAny variables are imported as ExternalWeak declarations. To
handle WeakAny more consistently and fix this issue:

1) Update helper doImportAsDefinition to properly flag WeakAny variables
   and aliases as not importing defintions.

   Update callers of doImportAsDefinition to remove now redundant checks for
   WeakAny aliases, or ignore aliases, as appropriate.

2) Add any !doImportAsDefinition GVs to DoNotLinkFromSource set during
   linking of the GV prototype, where we usually add GVs to the
   DoNotLinkFromSource set for other reasons.

   Remove now unnecessary adding of WeakAny aliases to
   DoNotLinkFromSource set from copyGlobalAliasProto.

   Remove now unnecessary guard against linking non-imported function
   bodies from ModuleLinker::run.

llvm-svn: 252626
2015-11-10 18:20:11 +00:00
Teresa Johnson f1b0a6e37c [ThinLTO] Always set linkage type to external when converting alias
When converting an alias to a non-alias when the aliasee is not
imported, ensure that the linkage type is set to external so that it is
a valid linkage type. Added a test case that exposed this issue.

llvm-svn: 252054
2015-11-04 16:01:16 +00:00
Teresa Johnson c7ed52f2ba Restore "Support for ThinLTO function importing and symbol linking."
This restores commit r251837, with the new library dependence added to
llvm-link/Makefile to address bot failures.

llvm-svn: 251866
2015-11-03 00:14:15 +00:00
Teresa Johnson 227a923140 Revert "Support for ThinLTO function importing and symbol linking."
This reverts commit r251837, due to a number of bot failures of the form:

/home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.obj/tools/llvm-link/Release+Asserts/llvm-link.o:llvm-link.cpp:function
loadIndex(llvm::LLVMContext&, llvm::Module const*): error: undefined
reference to
'llvm::object::FunctionIndexObjectFile::create(llvm::MemoryBufferRef,
llvm::LLVMContext&, llvm::Module const*, bool)'
/home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.obj/tools/llvm-link/Release+Asserts/llvm-link.o:llvm-link.cpp:function
loadIndex(llvm::LLVMContext&, llvm::Module const*): error: undefined
reference to 'llvm::object::FunctionIndexObjectFile::takeIndex()'

I'm not sure why these are happening - I added Object to the requred
libraries in tools/llvm-link/LLVMBuild.txt and the LLVM_LINK_COMPONENTS
in tools/llvm-link/CMakeLists.txt. Confirmed for my build that these
symbols come out of libLLVMObject.a. What am I missing?

llvm-svn: 251841
2015-11-02 22:17:32 +00:00
Teresa Johnson b1d4a39990 Support for ThinLTO function importing and symbol linking.
Summary:
Support for necessary linkage changes and symbol renaming during
ThinLTO function importing.

Also includes llvm-link support for manually importing functions
and associated llvm-link based tests.

Note that this does not include support for intelligently importing
metadata, which is currently imported duplicate times. That support will
be in the follow-on patch, and currently is ignored by the tests.

Reviewers: dexonsmith, joker.eph, davidxl

Subscribers: tobiasvk, tejohnson, llvm-commits

Differential Revision: http://reviews.llvm.org/D13515

llvm-svn: 251837
2015-11-02 21:39:10 +00:00