| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
Fix the condition for when the new global takes over the name of
the existing one to be the negation of the condition for the new
global to get internal linkage.
llvm-svn: 258355
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: mjacob
Subscribers: jholewinski, arsenm, dsanders, dblaikie
Patch by Eduard Burtescu.
Differential Revision: http://reviews.llvm.org/D16260
llvm-svn: 257999
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Function::copyAttributesFrom will copy the personality function, prefix
data and prolog data from the source function to the new function, and
is invoked when the IRMover copies the function prototype. This puts a
reference to a constant in the source module on a function in the dest
module, which causes an error when deleting the source module after
importing, since the personality function in the source module still has
uses (this would presumably also be an issue for the prologue and prefix
data). Remove the copies added to the dest copy when creating the new
prototype, as they are mapped properly when/if we link the function body.
llvm-svn: 257420
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the new in-place ThinLTO symbol handling support added in
r257174, we now invoke renameModuleForThinLTO on the current
module from within the FunctionImport pass.
Additionally, renameModuleForThinLTO no longer needs to return the
Module as it is performing the renaming in place on the one provided.
This commit will be immediately preceeded by a companion clang patch to
remove its invocation of renameModuleForThinLTO.
llvm-svn: 257181
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Move ThinLTO global value processing functions out of ModuleLinker and
into a new ThinLTOGlobalProcessor class, which performs any necessary
linkage and naming changes on the given module in place.
As a result, renameModuleForThinLTO no longer needs to create a new
Module when performing any necessary local to global promotion on a
module that we are possibly exporting from during a ThinLTO backend
compilation.
During function importing the ThinLTO processing is still invoked from
the ModuleLinker (via the new class), as it needs to perform renaming and
linkage changes on the source module, e.g. in order to get the correct
renaming during local to global promotion.
Reviewers: joker.eph
Subscribers: davidxl, llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D15696
llvm-svn: 257174
|
|
|
|
|
|
|
|
|
| |
Follow-up to r257000: DIImportedEntity can reach a DISubprogram via
its entity, but also via its scope. Handle the latter case as well.
PR26037.
llvm-svn: 257019
|
|
|
|
|
|
|
|
|
|
| |
It is illegal to have a null entity in a DIImportedEntity, so
we must link in a DISubprogram metadata node referenced by one,
even if the associated function is not linked in or inlined anywhere.
Fixes PR26037.
llvm-svn: 257000
|
|
|
|
|
|
|
|
| |
As suggested in review for r255909, rename MDMaterialized to AllowTemps,
and identify the name of the boolean flag being set in calls to
saveMetadataList.
llvm-svn: 256653
|
|
|
|
|
|
|
|
|
|
|
|
| |
As suggested in review for r255909, add a way to ensure that temporary
MD used as keys in the MetadataToID map during ThinLTO importing are not
RAUWed.
Add support for marking an MDNode as not replaceable. Clear the new
CanReplace flag when adding a temporary MD node to the MetadataToID map
and clear it when destroying the map.
llvm-svn: 256648
|
|
|
|
|
|
|
| |
Renamed MDValue* to Metadata*, and MDValueToValIDMap to MetadataToIDs,
as per review for r255909.
llvm-svn: 256593
|
|
|
|
|
|
|
|
| |
Use an iterator that handles an empty subprogram list.
Fixes PR25915.
llvm-svn: 256224
|
|
|
|
| |
llvm-svn: 256171
|
|
|
|
|
|
|
| |
Remove a couple ModuleLinker methods and a related static function that
are no longer used after the linker split.
llvm-svn: 256162
|
|
|
|
|
|
|
| |
It was only used on lib/Linker and the use was "dead" since it was used on a
function the IRMover had just moved.
llvm-svn: 256019
|
|
|
|
|
|
|
|
| |
Renamed variables to be more reflective of whether they are
an instance of Linker, IRLinker or ModuleLinker. Also fix a stale
comment.
llvm-svn: 256011
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Third patch split out from http://reviews.llvm.org/D14752.
Only map in needed DISubroutine metadata (imported or otherwise linked
in functions and other DISubroutine referenced by inlined instructions).
This is supported for ThinLTO, LTO and llvm-link --only-needed, with
associated tests for each one.
Depends on D14838.
Reviewers: dexonsmith, joker.eph
Subscribers: davidxl, llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D14843
llvm-svn: 256003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Second patch split out from http://reviews.llvm.org/D14752.
Maps metadata as a post-pass from each module when importing complete,
suturing up final metadata to the temporary metadata left on the
imported instructions.
This entails saving the mapping from bitcode value id to temporary
metadata in the importing pass, and from bitcode value id to final
metadata during the metadata linking postpass.
Depends on D14825.
Reviewers: dexonsmith, joker.eph
Subscribers: davidxl, llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D14838
llvm-svn: 255909
|
|
|
|
| |
llvm-svn: 255903
|
|
|
|
|
|
|
| |
Passing in a std::unique_ptr should help find errors when the module
is used after being linked into another module.
llvm-svn: 255842
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch converts code that has access to a LLVMContext to not take a
diagnostic handler.
This has a few advantages
* It is easier to use a consistent diagnostic handler in a single program.
* Less clutter since we are not passing a handler around.
It does make it a bit awkward to implement some C APIs that return a
diagnostic string. I will propose new versions of these APIs and
deprecate the current ones.
llvm-svn: 255571
|
|
|
|
| |
llvm-svn: 255272
|
|
|
|
|
|
| |
Found by ubsan.
llvm-svn: 255258
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A linker normally has two stages: symbol resolution and "moving stuff".
In lib/Linker there is the complication of lazy linking some globals,
but it was still far more mixed than it needed to.
This splits the linker into a lower level IRMover and the linker proper.
The IRMover just takes a list of globals to move and a callback that
lets the user control what is lazy linked.
The main motivation is that now tools/gold (and soon lld) can use their
own symbol resolution to instruct IRMover what to do.
llvm-svn: 255254
|
|
|
|
|
|
|
| |
We were deciding to not link an available_externally gv over a
declaration, but then copying over the body anyway.
llvm-svn: 255169
|
|
|
|
| |
llvm-svn: 255021
|
|
|
|
| |
llvm-svn: 254967
|
|
|
|
| |
llvm-svn: 254952
|
|
|
|
|
|
|
| |
We already linked available_externally and linkonce lazily, this just
adds declarations to the list.
llvm-svn: 254917
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now instead of changing it to the new format and then linking, it just
handles the old format while copying it over.
The main differences are:
* There is no rauw in the source module.
* An old format input is always upgraded.
The first item helps with having a sane API that passes in a GV list to
the linker.
The second one is a small step in deprecating the old format.
llvm-svn: 254907
|
|
|
|
|
|
|
|
|
| |
Creates a module and performs necessary renaming/promotion of locals
that may be exported to another module.
Split out of D15024.
llvm-svn: 254802
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch the diagnostic handler was optional. If it was not
passed, the one in the LLVMContext was used.
That is probably not a pattern we want to follow. If each area has an
optional callback, there is a sea of callbacks and it is hard to follow
which one is called.
Doing this also found cases where the callback is a nice addition, like
testing that no errors or warnings are reported.
The other option is to always use the diagnostic handler in the
LLVMContext. That has a few problems
* To implement the C API we would have to set the diag handler and then
set it back to the original value.
* Code that creates the context might be far away from code that wants
the diagnostics.
I do have a patch that implements the second option and will send that as
an RFC.
llvm-svn: 254777
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix import from module with appending var, which cannot be imported. The
first fix is to remove an overly-aggressive error check.
The second fix is to deal with restructuring introduced to the module
linker yesterday in r254418 (actually, this fix was included already
in r254559, just added some additional cleanup).
Test by Mehdi Amini.
Reviewers: joker.eph, rafael
Subscribers: joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D15156
llvm-svn: 254624
|
|
|
|
|
|
| |
We now just return values and let ValueMap handle the map.
llvm-svn: 254615
|
|
|
|
| |
llvm-svn: 254610
|
|
|
|
|
|
|
|
|
| |
accurately the actual use.
Thanks Sean Silva for the suggestion.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 254582
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is no real reason the index has to have the concept of an
exporting Module. We should be able to have one single unique
instance of the Index, and it should be read-only after creation
for the whole ThinLTO processing.
The linker plugin should be able to process multiple modules (in
parallel or in sequence) with the same index.
The only reason the ExportingModule was present seems to be to
implement hasExportedFunctions() that is used by the Module linker
to decide what to do with the current Module.
For now I replaced it with a query to the map of Modules path to
see if this module was declared in the Index and consider that if
it is the case then it is probably exporting function.
On the long term the Linker interface needs to evolve and this
call should not be needed anymore.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 254581
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This was an omission when handling COFF style comdats with local keys.
Should fix the sanitizer-windows bot.
llvm-svn: 254543
|
|
|
|
|
|
| |
They are independent.
llvm-svn: 254541
|
|
|
|
|
|
|
| |
We were failing to copy the fact that the GV is weak and in the case of
an alias, producing invalid IR.
llvm-svn: 254538
|
|
|
|
|
|
|
|
|
|
|
|
| |
single one
For efficiency reason, when importing multiple functions for the same Module,
we can avoid reparsing it every time.
Differential Revision: http://reviews.llvm.org/D15102
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 254486
|
|
|
|
| |
llvm-svn: 254473
|
|
|
|
| |
llvm-svn: 254466
|
|
|
|
| |
llvm-svn: 254465
|
|
|
|
| |
llvm-svn: 254457
|
|
|
|
|
|
|
| |
Most of the file has been changed recently and was already clang-format
clean.
llvm-svn: 254454
|
|
|
|
|
|
|
| |
The linker never takes ownership of a module or changes which module it
is refering to, making it natural to use references.
llvm-svn: 254449
|
|
|
|
| |
llvm-svn: 254436
|
|
|
|
| |
llvm-svn: 254435
|