Commit Graph

24 Commits

Author SHA1 Message Date
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Peter Collingbourne e06bac4796 Put "built-in" function definitions in global Used list, for LTO. (fix bug 34169)
When building with LTO, builtin functions that are defined but whose calls have not been inserted yet, get internalized. The Global Dead Code Elimination phase in the new LTO implementation then removes these function definitions. Later optimizations add calls to those functions, and the linker then dies complaining that there are no definitions. This CL fixes the new LTO implementation to check if a function is builtin, and if so, to not internalize (and later DCE) the function. As part of this fix I needed to move the RuntimeLibcalls.{def,h} files from the CodeGen subidrectory to the IR subdirectory. I have updated all the files that accessed those two files to access their new location.

Fixes PR34169

Patch by Caroline Tice!

Differential Revision: https://reviews.llvm.org/D49434

llvm-svn: 337847
2018-07-24 19:34:37 +00:00
Nico Weber 432a38838d IWYU for llvm-config.h in llvm, additions.
See r331124 for how I made a list of files missing the include.
I then ran this Python script:

    for f in open('filelist.txt'):
        f = f.strip()
        fl = open(f).readlines()

        found = False
        for i in xrange(len(fl)):
            p = '#include "llvm/'
            if not fl[i].startswith(p):
                continue
            if fl[i][len(p):] > 'Config':
                fl.insert(i, '#include "llvm/Config/llvm-config.h"\n')
                found = True
                break
        if not found:
            print 'not found', f
        else:
            open(f, 'w').write(''.join(fl))

and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p`
and tried to fix include ordering and whatnot.

No intended behavior change.

llvm-svn: 331184
2018-04-30 14:59:11 +00:00
David Blaikie 8820929011 Sink Analysis/ObjectUtil(canBeOmittedFromSymbolTable) into IR so it can be legitimately be used by Object/IRSymtab
llvm-svn: 328135
2018-03-21 19:23:45 +00:00
Peter Collingbourne 6c48462276 Object: Improve COFF irsymtab comdat representation.
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
2017-11-21 22:06:20 +00:00
Peter Collingbourne 4899a923db Object: Downgrade invalid weak externals from an assert fail to an llvm::Error when creating an irsymtab.
This fixes bitcode emission for modules containing invalid weak externals.

llvm-svn: 312686
2017-09-07 01:33:52 +00:00
Teresa Johnson a83c3f7879 [LTO] Prevent dead stripping and internalization of symbols with sections
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
2017-07-25 19:42:32 +00:00
Peter Collingbourne 99b98c21f2 Object: Teach irsymtab::read() to try to use the irsymtab that we wrote to disk.
Fixes PR27551.

Differential Revision: https://reviews.llvm.org/D33974

llvm-svn: 306488
2017-06-27 23:50:24 +00:00
Peter Collingbourne 53ed867da8 Object: Add version and producer fields to the irsymtab header. NFCI.
These will be necessary in order to handle upgrades from old bitcode
files.

Differential Revision: https://reviews.llvm.org/D33972

llvm-svn: 306486
2017-06-27 23:49:58 +00:00
Peter Collingbourne afaeed5322 Object: Have the irsymtab builder take a string table builder. NFCI.
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
2017-06-21 18:23:19 +00:00
Peter Collingbourne 89061b2224 IR: Replace the "Linker Options" module flag with "llvm.linker.options" named metadata.
The new metadata is easier to manipulate than module flags.

Differential Revision: https://reviews.llvm.org/D31349

llvm-svn: 305227
2017-06-12 20:10:48 +00:00
Peter Collingbourne dc8c01891f Object: Move datalayout check into irsymtab::build. NFCI.
This check is a requirement of the irsymtab builder, not of any
particular caller.

Differential Revision: https://reviews.llvm.org/D33970

llvm-svn: 305023
2017-06-08 22:04:24 +00:00
Peter Collingbourne 8dde4cba4c Bitcode: Introduce a BitcodeFileContents data type. NFCI.
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
2017-06-08 22:00:24 +00:00
Peter Collingbourne c00c2b246b Object: Factor out the code for creating the irsymtab for an arbitrary 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
2017-06-08 01:26:14 +00:00
Chandler Carruth 6bda14b313 Sort the remaining #include lines in include/... and lib/....
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
2017-06-06 11:49:48 +00:00
Peter Collingbourne fa58f7528e LTO: Mark undefined module asm symbols as used.
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
2017-04-26 17:53:39 +00:00
Eugene Zelenko 1df42fac54 [Object] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).
llvm-svn: 301275
2017-04-24 23:21:38 +00:00
Peter Collingbourne 76423dce15 Object: Shrink the size of irsymtab::Symbol by a word. NFCI.
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
2017-04-17 23:43:49 +00:00
Peter Collingbourne c74cf06ee4 Object: Use offset+size as the irsymtab string representation.
This is consistent with the bitcode string table.

Differential Revision: https://reviews.llvm.org/D31922

llvm-svn: 300465
2017-04-17 17:55:24 +00:00
Peter Collingbourne 8446f1fe6a Object, LTO: Add target triple to irsymtab and LTO API.
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
2017-04-14 02:55:06 +00:00
Tobias Edler von Koch 90df1f48d5 LTO: Pass SF_Executable flag through to InputFile::Symbol
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
2017-04-13 16:24:14 +00:00
Peter Collingbourne 7b30f16c9f Re-apply r299168 and r299169 now that the libdeps are fixed.
llvm-svn: 299184
2017-03-31 04:47:07 +00:00
Peter Collingbourne f10698b940 Revert r299168 and r299169 due to library dependency issues.
http://bb.pgr.jp/builders/i686-mingw32-RA-on-linux/builds/25073/steps/build_llvmclang/logs/stdio

llvm-svn: 299171
2017-03-31 02:44:50 +00:00
Peter Collingbourne d9717aa0e4 LTO: Reduce memory consumption by creating an in-memory symbol table for 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
2017-03-31 02:28:30 +00:00