summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Object/IRSymtab.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Object: Improve COFF irsymtab comdat representation.Peter Collingbourne2017-11-211-9/+36
| | | | | | | | | | | | Change the representation of COFF comdats so that a COFF linker is able to accurately resolve comdats between IR and native object files. Specifically, apply name mangling to comdat names consistently with native object files, and do not export comdats with an internal leader because they do not affect symbol resolution. Differential Revision: https://reviews.llvm.org/D40278 llvm-svn: 318805
* Object: Downgrade invalid weak externals from an assert fail to an ↵Peter Collingbourne2017-09-071-3/+6
| | | | | | | | llvm::Error when creating an irsymtab. This fixes bitcode emission for modules containing invalid weak externals. llvm-svn: 312686
* [LTO] Prevent dead stripping and internalization of symbols with sectionsTeresa Johnson2017-07-251-0/+4
| | | | | | | | | | | | | | | | | | | | | | | Summary: ELF linkers generate __start_<secname> and __stop_<secname> symbols when there is a value in a section <secname> where the name is a valid C identifier. If dead stripping determines that the values declared in section <secname> are dead, and we then internalize (and delete) such a symbol, programs that reference the corresponding start and end section symbols will get undefined reference linking errors. To fix this, add the section name to the IRSymtab entry when a symbol is defined in a specific section. Then use this in the gold-plugin to mark the symbol as external and visible from outside the summary when the section name is a valid C identifier. Reviewers: pcc Subscribers: mehdi_amini, inglorion, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D35639 llvm-svn: 309009
* Object: Teach irsymtab::read() to try to use the irsymtab that we wrote to disk.Peter Collingbourne2017-06-271-3/+27
| | | | | | | | Fixes PR27551. Differential Revision: https://reviews.llvm.org/D33974 llvm-svn: 306488
* Object: Add version and producer fields to the irsymtab header. NFCI.Peter Collingbourne2017-06-271-0/+18
| | | | | | | | | These will be necessary in order to handle upgrades from old bitcode files. Differential Revision: https://reviews.llvm.org/D33972 llvm-svn: 306486
* Object: Have the irsymtab builder take a string table builder. NFCI.Peter Collingbourne2017-06-211-17/+19
| | | | | | | | | This will be needed in order to share the irsymtab string table with the bitcode string table. Differential Revision: https://reviews.llvm.org/D33971 llvm-svn: 305937
* IR: Replace the "Linker Options" module flag with "llvm.linker.options" ↵Peter Collingbourne2017-06-121-3/+3
| | | | | | | | | | named metadata. The new metadata is easier to manipulate than module flags. Differential Revision: https://reviews.llvm.org/D31349 llvm-svn: 305227
* Object: Move datalayout check into irsymtab::build. NFCI.Peter Collingbourne2017-06-081-4/+4
| | | | | | | | | This check is a requirement of the irsymtab builder, not of any particular caller. Differential Revision: https://reviews.llvm.org/D33970 llvm-svn: 305023
* Bitcode: Introduce a BitcodeFileContents data type. NFCI.Peter Collingbourne2017-06-081-4/+13
| | | | | | | | | | This data type includes the contents of a bitcode file. Right now a bitcode file can only contain modules, but a later change will add a symbol table. Differential Revision: https://reviews.llvm.org/D33969 llvm-svn: 305019
* Object: Factor out the code for creating the irsymtab for an arbitrary ↵Peter Collingbourne2017-06-081-0/+34
| | | | | | | | | | | bitcode file. This code now lives in lib/Object. The idea is that it can now be reused by IRObjectFile among other things. Differential Revision: https://reviews.llvm.org/D31921 llvm-svn: 304958
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* LTO: Mark undefined module asm symbols as used.Peter Collingbourne2017-04-261-0/+3
| | | | | | | | | | | | | | | | Marking them as used causes them to be considered visible outside of LTO. This prevents the symbols from being internalized or discarded, either by GlobalDCE or by summary-based dead stripping in ThinLTO. This change makes it unnecessary to add these symbols to llvm.compiler.used in the backend, as the symbols are kept alive by virtue of being external, so remove the backend code that handles that. Fixes PR32798. Differential Revision: https://reviews.llvm.org/D32544 llvm-svn: 301438
* [Object] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko2017-04-241-3/+25
| | | | | | other minor fixes (NFC). llvm-svn: 301275
* Object: Shrink the size of irsymtab::Symbol by a word. NFCI.Peter Collingbourne2017-04-171-14/+18
| | | | | | | | | | Instead of storing an UncommonIndex on the Symbol, use a flag bit to store whether the Symbol has an Uncommon. This shrinks Chromium's .bc files (after D32061) by about 1%. Differential Revision: https://reviews.llvm.org/D32070 llvm-svn: 300514
* Object: Use offset+size as the irsymtab string representation.Peter Collingbourne2017-04-171-1/+2
| | | | | | | | This is consistent with the bitcode string table. Differential Revision: https://reviews.llvm.org/D31922 llvm-svn: 300465
* Object, LTO: Add target triple to irsymtab and LTO API.Peter Collingbourne2017-04-141-0/+1
| | | | | | | | | | Start using it in LLD to avoid needing to read bitcode again just to get the target triple, and in llvm-lto2 to avoid printing symbol table information that is inappropriate for the target. Differential Revision: https://reviews.llvm.org/D32038 llvm-svn: 300300
* LTO: Pass SF_Executable flag through to InputFile::SymbolTobias Edler von Koch2017-04-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The linker needs to be able to determine whether a symbol is text or data to handle the case of a common being overridden by a strong definition in an archive. If the archive contains a text member of the same name as the common, that function is discarded. However, if the archive contains a data member of the same name, that strong definition overrides the common. This is a behavior of ld.bfd, which the Qualcomm linker also supports in LTO. Here's a test case to illustrate: #### cat > 1.c << \! int blah; ! cat > 2.c << \! int blah() { return 0; } ! cat > 3.c << \! int blah = 20; ! clang -c 1.c clang -c 2.c clang -c 3.c ar cr lib.a 2.o 3.o ld 1.o lib.a -t #### The correct output is: 1.o (lib.a)3.o Thanks to Shankar Easwaran and Hemant Kulkarni for the test case! Reviewers: mehdi_amini, rafael, pcc, davide Reviewed By: pcc Subscribers: davide, llvm-commits, inglorion Differential Revision: https://reviews.llvm.org/D31901 llvm-svn: 300205
* Re-apply r299168 and r299169 now that the libdeps are fixed.Peter Collingbourne2017-03-311-0/+228
| | | | llvm-svn: 299184
* Revert r299168 and r299169 due to library dependency issues.Peter Collingbourne2017-03-311-228/+0
| | | | | | http://bb.pgr.jp/builders/i686-mingw32-RA-on-linux/builds/25073/steps/build_llvmclang/logs/stdio llvm-svn: 299171
* LTO: Reduce memory consumption by creating an in-memory symbol table for ↵Peter Collingbourne2017-03-311-0/+228
InputFiles. NFCI. Introduce symbol table data structures that can be potentially written to disk, have the LTO library build those data structures using temporarily constructed modules and redirect the LTO library implementation to go through those data structures. This allows us to remove the LLVMContext and Modules owned by InputFile. With this change I measured a peak memory consumption decrease from 5.4GB to 2.8GB in a no-op incremental ThinLTO link of Chromium on Linux. The impact on memory consumption is larger in COFF linkers where we are currently forced to materialize all metadata in order to read linker options. Peak memory consumption linking a large piece of Chromium for Windows with full LTO and debug info decreases from >64GB (OOM) to 15GB. Part of PR27551. Differential Revision: https://reviews.llvm.org/D31364 llvm-svn: 299168
OpenPOWER on IntegriCloud