| Age | Commit message (Collapse) | Author |
|---|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338104 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
When we're linking an alias which will be defined later, we neeed to
build a GlobalAlias, or else we'll crash later in
IRLinker::linkGlobalValueBody.
clang sometimes constructs aliases like this for C++ destructors.
Differential Revision: https://reviews.llvm.org/D49316
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337053 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Due to uniqueing of DICompositeTypes, it's possible for a type from one
module to be loaded into another earlier module without being renamed.
Then when the defining module is being IRMoved, the type can be used as
a Mapping destination before being loaded, such that when it's requested
using TypeMapTy::get() it will fail with an assertion that the type is a
source type when it's actually a type in both the source and
destination modules. Correctly handle that case by allowing a non-opaque
non-literal struct type be present in both modules.
Fix for PR37684.
Reviewers: pcc, tejohnson
Reviewed By: pcc, tejohnson
Subscribers: tobiasvk, mehdi_amini, steven_wu, llvm-commits, kcc
Differential Revision: https://reviews.llvm.org/D47898
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335145 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This wasreverted in r326638 due to link problems and fixed
afterwards
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327254 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This caused some links to fail with ThinLTO due to missing symbols as
well as causing some binaries to have failures at runtime. We're working
with the author to get a test case, but want to get the tree green
again.
Further, it appears to introduce a data race. While the test usage of
threads was disabled in r325361 & r325362, that isn't an acceptable fix.
I've reverted both of these as well. This code needs to be thread safe.
Test cases for this are already on the original commit thread.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326638 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts commit r325686.
There was a misunderstanding and this has not been approved yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325715 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential revision: https://reviews.llvm.org/D43199
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325686 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential revision: https://reviews.llvm.org/D43077
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325320 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325110 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@323407 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
With DebugTypeODRUniquing enabled, during IR linking debug metadata
in the destination module may be reached from the source module.
This means that ConstantAsMetadata nodes (e.g. on DITemplateValueParameter)
may contain a value the destination module. When trying to map such
metadata nodes, we will attempt to map a GV already in the dest module.
linkGlobalValueProto will end up with a source GV that is the same as
the dest GV as well as the new GV. Trying to access the TypeMap for the
source GV type, which is actually a dest GV type, hits an assertion
since it appears that we have mapped into the source module (because the
type is the value not a key into the map).
Detect that we don't need to access the TypeMap in this case, since
there is no need to create a bitcast from the new GV to the source GV
type as they GV are the same.
Fixes PR35722.
Reviewers: mehdi_amini, pcc
Subscribers: probinson, llvm-commits, eraman
Differential Revision: https://reviews.llvm.org/D41624
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322103 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
function type.
We were previously creating a global variable of function type,
which is invalid IR. This issue was exposed by r304690, in which we
started asserting that global variables were of a valid type.
Fixes PR33462.
Differential Revision: https://reviews.llvm.org/D36438
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@310543 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Linker::LinkOnlyNeeded should always import globals with
AppendingLinkage.
This resolves PR33527.
Differential Revision: https://reviews.llvm.org/D34448
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@310522 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
By prepending `.text .thumb .balign 2` to the module-level inline
assembly from a Thumb module, the assembler will generate the assembly
from that module as Thumb, even if the destination module uses an ARM
triple. Similar directives are used for module-level inline assembly in
ARM modules.
The alignment and instruction set are reset based on the target triple
before emitting the first function label.
Reviewers: olista01, tejohnson, echristo, t.p.northover, rafael
Reviewed By: echristo
Subscribers: aemerson, javed.absar, eraman, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D34622
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307772 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Add Max ModFlagBehavior, which can be used to take the max of two
module flag values when merging modules. Use it for the PIE and PIC
levels.
This avoids an error when we try to import from a module built -fpic
into a module built -fPIC, for example. For both PIE and PIC levels,
this will be legal, since the code generation gets more conservative
as the level is increased. Therefore we can take the max instead of
somehow trying to block importing between modules compiled with
different levels.
Reviewers: tmsriram, pcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33418
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@303590 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
compatible target triple
Currently, an assertion fails in ThinLTOCodeGenerator::addModule when
the target triple of the module being added doesn't match that of the
one stored in TMBuilder. This patch relaxes the constraint and makes
changes to allow target triples that only differ in their version
numbers on Apple platforms, similarly to what r228999 did.
rdar://problem/30133904
Differential Revision: https://reviews.llvm.org/D33291
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@303326 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The erase/remove from parent methods now use a switch table to remove
themselves from their appropriate parent ilist.
The copyAttributesFrom method is now completely non-virtual, since we
only ever copy attributes from a global of the appropriate type.
Pre-requisite to de-virtualizing Value to save a vptr
(https://reviews.llvm.org/D31261).
NFC
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302823 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential Revision: https://reviews.llvm.org/D30738
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297649 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Currently these flags are always the inverse of each other, so there is
no need to keep them separate.
Differential Revision: https://reviews.llvm.org/D29471
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294016 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential Revision: https://reviews.llvm.org/D29470
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294015 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The importer was previously using ModuleLinker in a sort of "IRMover mode". Use
IRMover directly instead in order to remove a level of indirection.
I will remove all importing support from ModuleLinker in a separate
change.
Differential Revision: https://reviews.llvm.org/D29468
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294014 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
NFCI.
The goal is to simplify the semantic model for clients of IRMover.
Differential Revision: https://reviews.llvm.org/D29435
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293864 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
As discussed on mailing list, for ThinLTO importing we don't need
to import all the fields of the DICompileUnit. Don't import enums,
macros, retained types lists. Also only import local scoped imported
entities. Since we don't currently import any global variables,
we also don't need to import the list of global variables (added an
assert to verify none are being imported).
This is being done by pre-populating the value map entries to map
the unneeded metadata to nullptr. For the imported entities, we can
simply replace the source module's list with a new list containing
only those needed imported entities. This is done in the IRLinker
constructor so that value mapping automatically does the desired
mapping.
Reviewers: mehdi_amini, dexonsmith, dblaikie, aprantl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27635
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289441 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Now that PointerType is no longer a SequentialType, all SequentialTypes
have an associated number of elements, so we can move that information to
the base class, allowing for a number of simplifications.
Differential Revision: https://reviews.llvm.org/D27122
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288464 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It seems that because ThinLTO does not import the full module,
some invariant of the type mapper are broken.
In Monolithic LTO, we import every globals: when calling
IRLinker::copyFunctionProto() on @foo(), we end-up calling
TypeMapTy::get(FTy) on the type of @foo(), which will map
%0 and record the destination as opaque.
ThinLTO skips this because @foo is not imported and goes directly
to the next stage.
Next we call computeTypeMapping() that map the types for each
globals, and ends up checking for type isomorphism, and may add
type mapping. However it doesn't record if there was an opaque
destination type that was resolved.
Instead of lazily "discovering" opaque type in the destination
module on the go, we change the TypeFinder to eagerly record all
types and not only the named ones.
Differential Revision: https://reviews.llvm.org/D26840
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287453 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
During Module linking, it's possible for SrcM->getIdentifiedStructTypes();
to return types that are actually defined in the destination module
(DstM). Depending on how the bitcode file was read,
getIdentifiedStructTypes() might do a walk over all values, including
metadata nodes, looking for types. In my case, a debug info metadata
node was shared between the two modules, and it referred to a type
defined in the destination module (see test case).
Differential Revision: https://reviews.llvm.org/D26212
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287353 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This was causing us to create duplicate metadata on global variables.
Debug info test case by Adrian Prantl, additional test cases by me.
Fixes PR31012.
Differential Revision: https://reviews.llvm.org/D26622
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286905 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286845 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential Revision: https://reviews.llvm.org/D26439
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286382 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284635 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Module inline asm was always being linked/concatenated
when running the IRLinker. This is correct for full LTO but not when
we are importing for ThinLTO, as it can result in multiply defined
symbols when the module asm defines a global symbol.
In order to test with llvm-lto2, I had to work around PR30396,
where a symbol that is defined in module assembly but defined in the
LLVM IR appears twice. Added workaround to llvm-lto2 with a FIXME.
Fixes PR30610.
Reviewers: mehdi_amini
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25359
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284030 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch reverses the edge from DIGlobalVariable to GlobalVariable.
This will allow us to more easily preserve debug info metadata when
manipulating global variables.
Fixes PR30362. A program for upgrading test cases is attached to that
bug.
Differential Revision: http://reviews.llvm.org/D20147
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281284 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Because the recent change about ODR type uniquing in the context,
we can reach types defined in another module during IR linking.
This triggered some assertions in case we IR link without starting
from an empty module. To alleviate that, we can self-map metadata
defined in the destination module so that they won't be visited.
Differential Revision: https://reviews.llvm.org/D23841
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280599 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This was indented really awkwardly, and clang-format didn't seem to
know how to do any better. Avoid the issue with a temporary variable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278756 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
No functionality change is intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278475 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The bitset metadata currently used in LLVM has a few problems:
1. It has the wrong name. The name "bitset" refers to an implementation
detail of one use of the metadata (i.e. its original use case, CFI).
This makes it harder to understand, as the name makes no sense in the
context of virtual call optimization.
2. It is represented using a global named metadata node, rather than
being directly associated with a global. This makes it harder to
manipulate the metadata when rebuilding global variables, summarise it
as part of ThinLTO and drop unused metadata when associated globals are
dropped. For this reason, CFI does not currently work correctly when
both CFI and vcall opt are enabled, as vcall opt needs to rebuild vtable
globals, and fails to associate metadata with the rebuilt globals. As I
understand it, the same problem could also affect ASan, which rebuilds
globals with a red zone.
This patch solves both of those problems in the following way:
1. Rename the metadata to "type metadata". This new name reflects how
the metadata is currently being used (i.e. to represent type information
for CFI and vtable opt). The new name is reflected in the name for the
associated intrinsic (llvm.type.test) and pass (LowerTypeTests).
2. Attach metadata directly to the globals that it pertains to, rather
than using the "llvm.bitsets" global metadata node as we are doing now.
This is done using the newly introduced capability to attach
metadata to global variables (r271348 and r271358).
See also: http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html
Differential Revision: http://reviews.llvm.org/D21053
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273729 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential Revision: http://reviews.llvm.org/D21624
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273692 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a resubmittion of previously reverted rL273568.
This is a fix for the problem mentioned in "LTO and intrinsics mangling" llvm-dev mail thread:
http://lists.llvm.org/pipermail/llvm-dev/2016-April/098387.html
Reviewers: mehdi_amini, reames
Differential Revision: http://reviews.llvm.org/D19373
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273686 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It broke 2008-07-15-Bswap.ll and 2009-09-01-PostRAProlog.ll
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273574 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a fix for the problem mentioned in "LTO and intrinsics mangling" llvm-dev mail thread:
http://lists.llvm.org/pipermail/llvm-dev/2016-April/098387.html
Reviewers: mehdi_amini, reames
Differential Revision: http://reviews.llvm.org/D19373
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273568 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
GlobalObject::copyAttributesFrom.
Summary: This reverts the changes to Globals.cpp and IRMover.cpp in
"[IR] Copy comdats in GlobalObject::copyAttributesFrom" (D20631,
rL270743).
The DeadArgElim test is left unchanged, and we change DAE to explicitly
copy comdats.
The reverted change breaks copyAttributesFrom when the destination lives
in a different module from the source. The decision in D21255 was to
revert this patch and handle comdat copying separately from
copyAttributesFrom.
Reviewers: majnemer, rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D21403
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272855 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
If a local_unnamed_addr attribute is attached to a global, the address
is known to be insignificant within the module. It is distinct from the
existing unnamed_addr attribute in that it only describes a local property
of the module rather than a global property of the symbol.
This attribute is intended to be used by the code generator and LTO to allow
the linker to decide whether the global needs to be in the symbol table. It is
possible to exclude a global from the symbol table if three things are true:
- This attribute is present on every instance of the global (which means that
the normal rule that the global must have a unique address can be broken without
being observable by the program by performing comparisons against the global's
address)
- The global has linkonce_odr linkage (which means that each linkage unit must have
its own copy of the global if it requires one, and the copy in each linkage unit
must be the same)
- It is a constant or a function (which means that the program cannot observe that
the unique-address rule has been broken by writing to the global)
Although this attribute could in principle be computed from the module
contents, LTO clients (i.e. linkers) will normally need to be able to compute
this property as part of symbol resolution, and it would be inefficient to
materialize every module just to compute it.
See:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html
for earlier discussion.
Part of the fix for PR27553.
Differential Revision: http://reviews.llvm.org/D20348
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272709 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Or replace with llvm::function_ref if it's never stored. NFC intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272513 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Avoids unnecessary copies. All changes audited & pass tests with asan.
No functional change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272190 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272013 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
No functionality change intended, maybe a tiny performance improvement.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270997 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This will be needed in order to consistently return an Error
to clients of the API being developed in D20268.
Differential Revision: http://reviews.llvm.org/D20550
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270967 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It may materialize a declaration, or a definition. The name could
be misleading. This is following a merge of materializeInitFor()
into materializeDeclFor().
Differential Revision: http://reviews.llvm.org/D20593
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270759 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
They were originally separated to handle the co-recursion between
the ValueMapper and the ValueMaterializer. This recursion does not
exist anymore: the ValueMapper now uses a Worklist and the
ValueMaterializer is scheduling job on the Worklist.
Differential Revision: http://reviews.llvm.org/D20593
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270758 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This test was hitting an assertion in the value mapper because
the IRLinker was trying to map two times @A while materializing
the initializer for @C.
Fix http://llvm.org/PR27850
Differential Revision: http://reviews.llvm.org/D20586
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270757 91177308-0d34-0410-b5e6-96231b3b80d8
|
