bcm5719-llvm/llvm/test/LTO/X86/Inputs, branch meklort-10.0.1

[LTO] Support for embedding bitcode section during LTO

2019-12-12T20:34:19+00:00

Summary: This adds support for embedding bitcode in a binary during LTO. The libLTO gains supports the `-lto-embed-bitcode` flag. The option allows users of the LTO library to embed a bitcode section. For example, LLD can pass the option via `ld.lld -mllvm=-lto-embed-bitcode`. This feature allows doing something comparable to `clang -c -fembed-bitcode`, but on the (LTO) linker level. Having bitcode alongside native code has many use-cases. To give an example, the MacOS linker can create a `-bitcode_bundle` section containing bitcode. Also, having this feature built into LLVM is an alternative to 3rd party tools such as [[ https://github.com/travitch/whole-program-llvm | wllvm ]] or [[ https://github.com/SRI-CSL/gllvm | gllvm ]]. As with these tools, this feature simplifies creating "whole-program" llvm bitcode files, but in contrast to wllvm/gllvm it does not rely on a specific llvm frontend/driver. Patch by Josef Eisl Reviewers: #llvm, #clang, rsmith, pcc, alexshap, tejohnson Reviewed By: tejohnson Subscribers: tejohnson, mehdi_amini, inglorion, hiraditya, aheejin, steven_wu, dexonsmith, dang, cfe-commits, llvm-commits, #llvm, #clang Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68213

[IRMover] Don't map globals if their types are the same

2019-09-11T18:35:49+00:00

Summary: During IR Linking, if the types of two globals in destination and source modules are the same, it can only be because the global in the destination module is originally from the source module and got added to the destination module from a shared metadata. We shouldn't map this type to itself in case the type's components get remapped to a new type from the destination (for instance, during the loop over SrcM->getIdentifiedStructTypes() further below in IRLinker::computeTypeMapping()). Fixes PR40312. Reviewers: tejohnson, pcc, srhines Subscribers: mehdi_amini, hiraditya, steven_wu, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66814 llvm-svn: 371643

Reland "Change the X86 datalayout to add three address spaces

2019-09-10T23:15:38+00:00

for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568

Revert "Change the X86 datalayout to add three address spaces for 32 bit signed,"

2019-08-28T01:08:54+00:00

This reverts commit r370083 because it caused check-lld failures on sanitizer-x86_64-linux-fast. llvm-svn: 370142

Change the X86 datalayout to add three address spaces for 32 bit signed,

2019-08-27T17:46:53+00:00

32 bit unsigned, and 64 bit pointers. llvm-svn: 370083

[NFC] Adjust "invalid.ll.bc" tests to check for AttrKind #255 not #63

2019-07-11T01:14:30+00:00

We are about to add enum attributes with AttrKind numbers >= 63. This means we cannot use AttrKind #63 to test for an invalid attribute number in the RAW format anymore. This patch changes the number of an invalid attribute to #255. There is no change to the character of the tests. Differential Revision: https://reviews.llvm.org/D64531 llvm-svn: 365722

[ThinLTO]LTO]Legacy] Fix dependent libraries support by adding querying of the IRSymtab

2019-06-12T11:07:56+00:00

Dependent libraries support for the legacy api was committed in a broken state (see: https://reviews.llvm.org/D60274). This was missed due to the painful nature of having to integrate the changes into a linker in order to test. This change implements support for dependent libraries in the legacy LTO api: - I have removed the current api function, which returns a single string, and added functions to access each dependent library specifier individually. - To reduce the testing pain, I have made the api functions as thin as possible to maximize coverage from llvm-lto. - When doing ThinLTO the system linker will load the modules lazily when scanning the input files. Unfortunately, when modules are lazily loaded there is no access to module level named metadata. To fix this I have added api functions that allow querying the IRSymtab for the dependent libraries. I hope to expand the api in the future so that, eventually, all the information needed by a client linker during scan can be retrieved from the IRSymtab. Differential Revision: https://reviews.llvm.org/D62935 llvm-svn: 363140

Revert [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols

2019-04-08T18:53:21+00:00

This reverts r357931 (git commit 8b70a5c11e08116955a875b9085433f14737bcaf) llvm-svn: 357932

[ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols

2019-04-08T18:24:10+00:00

Summary: ThinLTOCodeGenerator currently does not preserve llvm.used symbols and it can internalize them. In order to pass the necessary information to the legacy ThinLTOCodeGenerator, the input to the code generator is rewritten to be based on lto::InputFile. This fixes: PR41236 rdar://problem/49293439 Reviewers: tejohnson, pcc, dexonsmith Reviewed By: tejohnson Subscribers: mehdi_amini, inglorion, eraman, hiraditya, jkorous, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60226 llvm-svn: 357931

Pass code-model through Module IR to LTO which will use it.

2018-09-21T18:41:31+00:00

Currently the code-model does not get saved in the module IR, so if a code model is specified when compiling with LTO, it gets lost and is not propagated properly to LTO. This patch, along with one for the front end, fixes that. Differential Revision: https://reviews.llvm.org/D52322 llvm-svn: 342760