Commit Graph

199 Commits

Author SHA1 Message Date
Simon Atanasyan e12bef7ea7 ValueMapper: Fix unused var warning. NFC
llvm-svn: 266529
2016-04-16 11:49:40 +00:00
Duncan P. N. Exon Smith a77d073305 ValueMapper: Stop memoizing ConstantAsMetadata
Stop memoizing ConstantAsMetadata in ValueMapper::mapMetadata.  Now we
have to recompute it, but these metadata aren't particularly common, and
it restricts the lifetime of the Metadata map unnecessarily.

(The motivation is that I have a patch which uses a single Metadata map
for the lifetime of IRMover.  Mehdi profiled r266446 with the patch
applied and we saw a pretty big speedup in lib/Linker.)

llvm-svn: 266513
2016-04-16 03:39:44 +00:00
Duncan P. N. Exon Smith 39423b0294 Reapply "ValueMapper: Eliminate cross-file co-recursion, NFC"
This reverts commit r266507, reapplying r266503 (and r266505
"ValueMapper: Use API from r266503 in unit tests, NFC") completely
unchanged.

I reverted because of a bot failure here:
  http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/16810/

However, looking more closely, the failure was from a host-compiler
crash (clang 3.7.1) when building:
  lib/CodeGen/AsmPrinter/CMakeFiles/LLVMAsmPrinter.dir/DwarfAccelTable.cpp.o

I didn't modify that file, or anything it includes, with that commit.

The next build (which hadn't picked up my revert) got past it:
  http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/16811/

I think this was just unfortunate timing.  I suppose the bot must be
flakey.

llvm-svn: 266510
2016-04-16 02:29:55 +00:00
Duncan P. N. Exon Smith 6fe1ff260b Revert "ValueMapper: Eliminate cross-file co-recursion, NFC"
This reverts commit r266503, in case it's the root cause of this bot
failure:

  http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/16810

I'm also reverting r266505 -- "ValueMapper: Use API from r266503 in unit
tests, NFC" -- since it's in the way.

llvm-svn: 266507
2016-04-16 02:05:33 +00:00
Duncan P. N. Exon Smith f0d73f95c1 ValueMapper: Eliminate cross-file co-recursion, NFC
Eliminate co-recursion of Mapper::mapValue through
ValueMaterializer::materializeInitFor, through a major redesign of the
ValueMapper.cpp interface.

  - Expose a ValueMapper class that controls the entry points to the
    mapping algorithms.
  - Change IRLinker to use ValueMapper directly, rather than
    llvm::RemapInstruction, llvm::MapValue, etc.
  - Use (e.g.) ValueMapper::scheduleMapGlobalInit to add mapping work to
    a worklist in ValueMapper instead of recursing.

There were two fairly major complications.

Firstly, IRLinker::linkAppendingVarProto incorporates an on-the-fly IR
ugprade that I had to split apart.  Long-term, this upgrade should be
done in the bitcode reader (and we should only accept the "new" form),
but for now I've just made it work and added a FIXME.  The hold-op is
that we need to deprecate C API that relies on this.

Secondly, IRLinker has special logic to correctly implement aliases with
comdats, and uses two ValueToValueMapTy instances and two
ValueMaterializers.  I supported this by allowing clients to register an
alternate mapping context, whose MCID can be passed in when scheduling
new work.

While out of scope for this commit, it should now be straightforward to
remove recursion from Mapper::mapValue.

llvm-svn: 266503
2016-04-16 01:29:08 +00:00
Duncan P. N. Exon Smith db6861e7dd ValueMapper: Hide Mapper::VM behind an accessor, NFC
Change Mapper::VM to a pointer and add a `getVM()` accessor for it.
While this has no functionality change, it minimizes the diff on an
upcoming patch that allows switching between instances of
ValueToValueMapTy on a single Mapper instance.

llvm-svn: 266490
2016-04-15 23:18:43 +00:00
Davide Italiano 96d2a1c603 [ValueMapper] Range-loopify to improve readability. NFC.
llvm-svn: 266350
2016-04-14 18:07:32 +00:00
Duncan P. N. Exon Smith 11f60fd65a ValueMapper: Resolve cycles on the new nodes
Fix a major bug from r265456.  Although it's now much rarer, ValueMapper
sometimes has to duplicate cycles.  The
might-transitively-reference-a-temporary counts don't decrement on their
own when there are cycles, and you need to call MDNode::resolveCycles to
fix it.

r265456 was checking the input nodes to see if they were unresolved.
This is useless; they should never be unresolved.  Instead we should
check the output nodes and resolve cycles on them.

llvm-svn: 266258
2016-04-13 22:54:01 +00:00
Duncan P. N. Exon Smith bb2c3e199e ValueMapper: Extract llvm::RemapFunction from IRMover.cpp, NFC
Strip out the remapping parts of IRLinker::linkFunctionBody and put them
in ValueMapper.cpp under the name Mapper::remapFunction (with a
top-level entry-point llvm::RemapFunction).

This is a nice cleanup on its own since it puts the remapping code
together and shares a single Mapper context for the entire
IRLinker::linkFunctionBody Call.  Besides that, this will make it easier
to break the co-recursion between IRMover.cpp and ValueMapper.cpp in
follow ups.

llvm-svn: 265835
2016-04-08 19:26:32 +00:00
Duncan P. N. Exon Smith adcebdf2d1 ValueMapper: Always use Mapper::mapValue from remapInstruction, NFCI
Use Mapper::mapValue instead of llvm::MapValue from
Mapper::remapInstruction when mapping an incoming block for a PHINode
(follow-up to r265832).  This will implicitly pass along the
Materializer argument, but when this code was added in r133513 there was
no Materializer argument.  I suspect this call to MapValue was just
missed in r182776 since it's not observable (basic blocks can't be
materialized, and they don't reference other values).

llvm-svn: 265833
2016-04-08 19:17:13 +00:00
Duncan P. N. Exon Smith a574e7a7a4 ValueMapper: Roll RemapInstruction into Mapper, NFC
Add Mapper::remapInstruction, move the guts of llvm::RemapInstruction
into it, and use the same Mapper for most of the calls to MapValue and
MapMetadata.  There should be no functionality change here.

I left off the call to MapValue that wasn't passing in a Materializer
argument (for basic blocks of PHINodes).  It shouldn't change
functionality either, but I'm suspicious enough to commit separately.

llvm-svn: 265832
2016-04-08 19:09:34 +00:00
Duncan P. N. Exon Smith 69341e6abc ValueMapper: Don't memoize metadata when RF_NoModuleLevelChanges
Prevent the Metadata side-table in ValueMap from growing unnecessarily
when RF_NoModuleLevelChanges.  As a drive-by, make ValueMap::hasMD,
which apparently had no users until I used it here for testing, actually
compile.

llvm-svn: 265828
2016-04-08 18:49:36 +00:00
Duncan P. N. Exon Smith e05ff7c1a7 ValueMapper: Stop memoizing MDStrings
Stop adding MDString to the Metadata section of the ValueMap in
MapMetadata.  It blows up the size of the map for no benefit, since we
can always return quickly anyway.

There is a potential follow-up that I don't think I'll push on right
away, but maybe someone else is interested:  stop checking for a
pre-mapped MDString, and move the `isa<MDString>()` checks in
Mapper::mapSimpleMetadata and MDNodeMapper::getMappedOp in front of the
`VM.getMappedMD()` calls.  While this would preclude explicitly
remapping MDStrings it would probably be a little faster.

llvm-svn: 265827
2016-04-08 18:47:02 +00:00
Duncan P. N. Exon Smith 4ec55f8ab6 Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"
This reverts commit r265765, reapplying r265759 after changing a call from
LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test).  When a
local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug
intrinsic operand may no longer be pointing at a local.

    http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/

The previous coommit message follows:

--

This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).

This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy.  In particular:

  - MapValue returns nullptr or "metadata !{}" for missing locals in
    MetadataAsValue/LocalAsMetadata bridging paris, depending on
    the RF_IgnoreMissingLocals flag.

  - MapValue doesn't memoize LocalAsMetadata-related results.

  - MapMetadata no longer deals with LocalAsMetadata or
    RF_IgnoreMissingLocals at all.  (This wasn't in r265631 at all, but
    I realized during testing it would make the patch simpler with no
    loss of generality.)

r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals.  This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:

    define void @foo(i32 %arg) {
      call void @llvm.some.intrinsic(metadata i32 %x)
      %x = add i32 1, i32 %arg
    }

If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.

I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.

As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset.  Otherwise, match
the behaviour of r265631.

Original commit message:

    ValueMapper: Make LocalAsMetadata match function-local Values

    Start treating LocalAsMetadata similarly to function-local members of
    the Value hierarchy in MapValue and MapMetadata.

      - Don't memoize them.
      - Return nullptr if they are missing.

    This also cleans up ConstantAsMetadata to stop listening to the
    RF_IgnoreMissingLocals flag.

llvm-svn: 265768
2016-04-08 03:13:22 +00:00
Duncan P. N. Exon Smith 805873148a Revert "ValueMapper: Treat LocalAsMetadata more like function-local Values"
This reverts commit r265759, since even this limited version breaks some
bots:
  http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/3311
  http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/17696

This also reverts r265761 "ValueMapper: Unduplicate
RF_NoModuleLevelChanges check, NFC", since I had trouble separating it
from r265759.

llvm-svn: 265765
2016-04-08 00:56:21 +00:00
Duncan P. N. Exon Smith 0fa8aca0e6 ValueMapper: Unduplicate RF_NoModuleLevelChanges check, NFC
llvm-svn: 265761
2016-04-08 00:41:10 +00:00
Duncan P. N. Exon Smith 267185ec92 ValueMapper: Treat LocalAsMetadata more like function-local Values
This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).

This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy.  In particular:

  - MapValue returns nullptr or "metadata !{}" for missing locals in
    MetadataAsValue/LocalAsMetadata bridging paris, depending on
    the RF_IgnoreMissingLocals flag.

  - MapValue doesn't memoize LocalAsMetadata-related results.

  - MapMetadata no longer deals with LocalAsMetadata or
    RF_IgnoreMissingLocals at all.  (This wasn't in r265631 at all, but
    I realized during testing it would make the patch simpler with no
    loss of generality.)

r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals.  This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:

    define void @foo(i32 %arg) {
      call void @llvm.some.intrinsic(metadata i32 %x)
      %x = add i32 1, i32 %arg
    }

If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.

I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.

As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset.  Otherwise, match
the behaviour of r265631.

Original commit message:

    ValueMapper: Make LocalAsMetadata match function-local Values

    Start treating LocalAsMetadata similarly to function-local members of
    the Value hierarchy in MapValue and MapMetadata.

      - Don't memoize them.
      - Return nullptr if they are missing.

    This also cleans up ConstantAsMetadata to stop listening to the
    RF_IgnoreMissingLocals flag.

llvm-svn: 265759
2016-04-08 00:33:44 +00:00
Duncan P. N. Exon Smith 45601e867d Revert "ValueMapper: Make LocalAsMetadata match function-local Values"
This reverts commit r265631, since it caused bot failures:
http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/3256
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/7272

Looks like something is depending on the old behaviour.  I'll try to
track it down and recommit.

llvm-svn: 265637
2016-04-07 02:10:50 +00:00
Duncan P. N. Exon Smith fdccad925c ValueMapper: Allow RF_IgnoreMissingLocals and RF_NullMapMissingGlobalValues
Remove the assertion that disallowed the combination, since
RF_IgnoreMissingLocals should have no effect on globals.  As it happens,
RF_NullMapMissingGlobalValues asserted in MapValue(Constant*,...), so I
also changed a cast to a cast_or_null to get my test passing.

llvm-svn: 265633
2016-04-07 01:22:45 +00:00
Duncan P. N. Exon Smith c1e4070708 ValueMapper: Make LocalAsMetadata match function-local Values
Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.

  - Don't memoize them.
  - Return nullptr if they are missing.

This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.

llvm-svn: 265631
2016-04-07 01:08:39 +00:00
Duncan P. N. Exon Smith da68cbc4ad IR: RF_IgnoreMissingValues => RF_IgnoreMissingLocals, NFC
Clarify what this RemapFlag actually means.

  - Change the flag name to match its intended behaviour.
  - Clearly document that it's not supposed to affect globals.
  - Add a host of FIXMEs to indicate how to fix the behaviour to match
    the intent of the flag.

RF_IgnoreMissingLocals should only affect the behaviour of
RemapInstruction for function-local operands; namely, for operands of
type Argument, Instruction, and BasicBlock.  Currently, it is *only*
passed into RemapInstruction calls (and the transitive MapValue calls
that it makes).

When I split Metadata from Value I didn't understand the flag, and I
used it in a bunch of places for "global" metadata.

This commit doesn't have any functionality change, but prepares to
cleanup MapMetadata and MapValue.

llvm-svn: 265628
2016-04-07 00:26:43 +00:00
Duncan P. N. Exon Smith 6f2e37429a ValueMapper: Fix delayed blockaddress handling after r265273
r265273 added Mapper::mapBlockAddress, which delays mapping a
blockaddress value until the function has a body.  The condition was
backwards, and should be checking Function::empty instead of
GlobalValue::isDeclaration.

llvm-svn: 265508
2016-04-06 02:25:12 +00:00
Duncan P. N. Exon Smith 818e5f38d2 Try harder to appease MSVC after r265456
r265465 wasn't good enough.  I need to spell out all the moves.

llvm-svn: 265470
2016-04-05 21:25:33 +00:00
Duncan P. N. Exon Smith f880d35b80 Try to appease MSVC after r265456
I can't remember if adding `= default` will make MSVC happy, or if I
have to spell this out.  Let's try the cleaner version first.

llvm-svn: 265465
2016-04-05 21:07:01 +00:00
Duncan P. N. Exon Smith ea7df770ae ValueMapper: Rewrite Mapper::mapMetadata without recursion
This commit completely rewrites Mapper::mapMetadata (the implementation
of llvm::MapMetadata) using an iterative algorithm.  The guts of the new
algorithm are in MDNodeMapper::map, the entry function in a new class.

Previously, Mapper::mapMetadata performed a recursive exploration of the
graph with eager "just in case there's a reason" malloc traffic.

The new algorithm has these benefits:

  - New nodes and temporaries are not created eagerly.
  - Uniquing cycles are not duplicated (see new unit test).
  - No recursion.

Given a node to map, it does this:

 1. Use a worklist to perform a post-order traversal of the transitively
    referenced unmapped nodes.

 2. Track which nodes will change operands, and which will have new
    addresses in the mapped scheme.  Propagate the changes through the
    POT until fixed point, to pick up uniquing cycles that need to
    change.

 3. Map all the distinct nodes without touching their operands.  If
    RF_MoveDistinctMetadata, they get mapped to themselves; otherwise,
    they get mapped to clones.

 4. Map the uniqued nodes (bottom-up), lazily creating temporaries for
    forward references as needed.

 5. Remap the operands of the distinct nodes.

Mehdi helped me out by profiling this with -flto=thin.  On his workload
(importing/etc. for opt.cpp), MapMetadata sped up by 15%, contributed
about 50% less to persistent memory, and made about 100x fewer calls to
malloc.  The speedup is less than I'd hoped.  The profile mainly blames
DenseMap lookups; perhaps there's a way to reduce them (e.g., by
disallowing remapping of MDString).

It would be nice to break the strange remaining recursion on the Value
side: MapValue => materializeInitFor => RemapInstruction => MapValue.  I
think we could do this by having materializeInitFor return a worklist of
things to be remapped.

llvm-svn: 265456
2016-04-05 20:23:21 +00:00
Duncan P. N. Exon Smith 8e65f8ddfd ValueMapper: Remove old FIXMEs; almost NFC
Remove a few old FIXMEs from the original commit of the Metadata/Value
split in r223802.  These are commented out assertions to the effect that
calls between mapValue and mapMetadata never return nullptr.

(The only behaviour change is that Mapper::mapSimpleMetadata memoizes
the nullptr return.)

When I originally rewrote the mapping code, I thought we could be
stricter in the new metadata hierarchy and never return nullptr when
RF_NullMapMissingGlobalValues was off.  It's still not entirely clear to
me why these assertions failed (a few months ago, I had a theory that I
forgot to write down, but that's helping no one).

Understood or not, I no longer see how these commented-out assertions
would be useful.  I'm relegating them to the annals of source control
before making significant changes to ValueMapper.cpp.

llvm-svn: 265282
2016-04-04 04:59:56 +00:00
Duncan P. N. Exon Smith 756e1c3db4 ValueMapper: Disallow metadata mapping recursion through mapValue
This adds an assertion to maintain the property from r265273.  When
Mapper::mapSimpleMetadata calls Mapper::mapValue, it should not find its
way back to mapMetadataImpl.  This guarantees that mapSimpleMetadata is
not involved in any recursion.

Since Mapper::mapValue calls out to arbitrary materializers, we need to
save a bit on the ValueMap to make this assertion effective.

There should be no functionality change here.  This co-recursion should
already have been impossible.

llvm-svn: 265276
2016-04-03 20:54:51 +00:00
Duncan P. N. Exon Smith a997856b3d Work around MSVC failure from r265273
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/19726

llvm-svn: 265275
2016-04-03 20:42:21 +00:00
Duncan P. N. Exon Smith c6065e3a25 ValueMapper: Avoid recursion in mapSimplifiedMetadata, NFC
The main change is to delay materializing GlobalValue initializers from
Mapper::mapValue until Mapper::~Mapper.  This effectively removes all
recursion from mapSimplifiedMetadata, as promised in r265270.
mapSimplifiedMetadata calls mapValue for ConstantAsMetadata nodes to
find the mapped constant, and now it shouldn't be possible for mapValue
to indirectly re-invoke mapMetadata.  I'll add an assertion to that
effect in a follow-up (separated so that the assertion can easily be
reverted independently, if it comes to that).

This a step toward a broader goal: converting Mapper::mapMetadataImpl
from a recursive to an iterative algorithm.

When a BlockAddress points at a BasicBlock inside an unmaterialized
function body, we need to delay it until the function body is
materialized in Mapper::~Mapper.  This commit creates a temporary
BasicBlock and returns a new BlockAddress, then RAUWs the BasicBlock
once it is known.  This situation should be extremely rare since a
BlockAddress is usually used from within the function it's referencing
(and BlockAddress itself is rare).

There should be no observable functionality change.

llvm-svn: 265273
2016-04-03 20:17:45 +00:00
Duncan P. N. Exon Smith ae8bd4bd11 ValueMapper: Split out mapSimpleMetadata, NFC
Split out a helper for mapping metadata without operands.  This is any
metadata that is not an MDNode, and any MDNode where the answer is known
without looking at operands.

Through some weird twists, this function is co-recursive:

    mapSimpleMetadata
    => MapValue
    => materializeInitFor
    => linkFunctionBody
    => RemapInstructions
    => MapMetadata
    => mapSimpleMetadata

I plan to break the recursion in a follow-up.

llvm-svn: 265270
2016-04-03 19:31:01 +00:00
Duncan P. N. Exon Smith 829dc87a68 ValueMapper: Introduce Mapper helper class, NFC
Remove a bunch of boilerplate from ValueMapper.cpp by using a new
file-local class called Mapper.

llvm-svn: 265268
2016-04-03 19:06:24 +00:00
Duncan P. N. Exon Smith 4b520e5ef6 Linker: Remove IRMover::isMetadataUnneeded indirection; almost NFC
Instead of checking live during MapMetadata whether a subprogram is
needed, seed the ValueMap with `nullptr` up-front.

There is a small hypothetical functionality change.  Previously, calling
MapMetadataOp on a node whose "scope:" chain led to an unneeded
subprogram would return nullptr.  However, if that were ever called,
then the subprogram would be needed; a situation that the IRMover is
supposed to avoid a priori!

Besides cleaning up the code a little, this restores a nice property:
MapMetadataOp returns the same as MapMetadata.

llvm-svn: 265229
2016-04-02 17:12:00 +00:00
Duncan P. N. Exon Smith da4a56d1ab ValueMapper: Add support for seeding metadata with nullptr
Support seeding a ValueMap with nullptr for Metadata entries, a
situation I didn't consider in the Metadata/Value split.

I added a ValueMapper::getMappedMD accessor that returns an
Optional<Metadata*> with the mapped (possibly null) metadata.  IRMover
needs to use this to avoid modifying the map when it's checking for
unneeded subprograms.  I updated a call from bugpoint since I find the
new code clearer.

llvm-svn: 265228
2016-04-02 17:04:38 +00:00
Teresa Johnson b703c77b03 [ThinLTO] Remove post-pass metadata linking support
Since we have moved to a model where functions are imported in bulk from
each source module after making summary-based importing decisions, there
is no longer a need to link metadata as a postpass, and all users have
been removed.

This essentially reverts r255909 and follow-on fixes.

llvm-svn: 264763
2016-03-29 18:24:19 +00:00
Teresa Johnson b43257d594 Split resolveCycles(bool AllowTemps) into two interfaces and document
Address review feedback from r255909.

Move body of resolveCycles(bool AllowTemps) to
resolveRecursivelyImpl(bool AllowTemps). Revert resolveCycles back
to asserting on temps, and add new resolveNonTemporaries interface
to invoke the new implementation with AllowTemps=true. Document
the differences between these interfaces, specifically the effect
on RAUW support and uniquing. Call appropriate interface from
ValueMapper.

llvm-svn: 257389
2016-01-11 21:37:41 +00:00
Teresa Johnson 96f7f81aa3 [ThinLTO] Rename variables used in metadata linking (NFC)
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
2015-12-30 21:13:55 +00:00
Teresa Johnson 0e7c82cb69 [ThinLTO/LTO] Don't link in unneeded metadata
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
2015-12-18 17:51:37 +00:00
Teresa Johnson e5a6191732 [ThinLTO] Metadata linking for imported functions
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
2015-12-17 17:14:09 +00:00
Rafael Espindola baa3bf8f76 Bring r254336 back:
The difference is that now we don't error on out-of-comdat access to
internal global values. We copy them instead. This seems to match the
expectation of COFF linkers (see pr25686).

Original message:

    Start deciding earlier what to link.

    A traditional linker is roughly split in symbol resolution and
"copying
    stuff".

    The two tasks are badly mixed in lib/Linker.

    This starts splitting them apart.

    With this patch there are no direct call to linkGlobalValueBody or
    linkGlobalValueProto. Everything is linked via WapValue.

    This also includes a few fixes:
    * A GV goes undefined if the comdat is dropped (comdat11.ll).
    * We error if an internal GV goes undefined (comdat13.ll).
    * We don't link an unused comdat.

    The first two match the behavior of an ELF linker. The second one is
    equivalent to running globaldce on the input.

llvm-svn: 254418
2015-12-01 15:19:48 +00:00
Rafael Espindola e9841a6bb5 This reverts commit r254336 and r254344.
They broke a bot and I am debugging why.

llvm-svn: 254347
2015-11-30 23:54:19 +00:00
Rafael Espindola c109200c53 Start deciding earlier what to link.
A traditional linker is roughly split in symbol resolution and "copying
stuff".

The two tasks are badly mixed in lib/Linker.

This starts splitting them apart.

With this patch there are no direct call to linkGlobalValueBody or
linkGlobalValueProto. Everything is linked via WapValue.

This also includes a few fixes:
* A GV goes undefined if the comdat is dropped (comdat11.ll).
* We error if an internal GV goes undefined (comdat13.ll).
* We don't link an unused comdat.

The first two match the behavior of an ELF linker. The second one is
equivalent to running globaldce on the input.

llvm-svn: 254336
2015-11-30 22:01:43 +00:00
Rafael Espindola 19b52383c5 Simplify the linking of recursive data.
Now the ValueMapper has two callbacks. The first one maps the
declaration. The ValueMapper records the mapping and then materializes
the body/initializer.

llvm-svn: 254209
2015-11-27 20:28:19 +00:00
Teresa Johnson 83d03ddbf6 Fix mapping of unmaterialized global values during metadata linking
Summary:
The patch to move metadata linking after global value linking didn't
correctly map unmaterialized global values to null as desired. They
were in fact mapped to the source copy. It largely worked by accident
since most module linker clients destroyed the source module which
caused the source GVs to be replaced by null, but caused a failure with
LTO linking on Windows:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312869.html

The problem is that a null return value from materializeValueFor is
handled by mapping the value to self. This is the desired behavior when
materializeValueFor is passed a non-GlobalValue. The problem is how to
distinguish that case from the case where we really do want to map to
null.

This patch addresses this by passing in a new flag to the value mapper
indicating that unmapped global values should be mapped to null. Other
Value types are handled as before.

Note that the documented behavior of asserting on unmapped values when
the flag RF_IgnoreMissingValues isn't set is currently disabled with
FIXME notes due to bootstrap failures. I modified these disabled asserts
so when they are eventually enabled again it won't assert for the
unmapped values when the new RF_NullMapMissingGlobalValues flag is set.

I also considered using a callback into the value materializer, but a
flag seemed cleaner given that there are already existing flags.
I also considered modifying materializeValueFor to return the input
value when we want to map to source and then treat a null return
to mean map to null. However, there are other value materializer
subclasses that implement materializeValueFor, and they would all need
to be audited and the return values possibly changed, which seemed
error-prone.

Reviewers: dexonsmith, joker.eph

Subscribers: pcc, llvm-commits

Differential Revision: http://reviews.llvm.org/D14682

llvm-svn: 253170
2015-11-15 14:50:14 +00:00
David Blaikie 88208840b5 [opaque pointer type]: Pass explicit pointee type when building a constant GEP.
Gets a bit tricky in the ValueMapper, of course - not sure if we should
just expose a list of explicit types for each Value so that the
ValueMapper can be neutral to these special cases (it's OK for things
like load, where the explicit type is the result type - but when that's
not the case, it means plumbing through another "special" type... )

llvm-svn: 245728
2015-08-21 20:16:51 +00:00
Duncan P. N. Exon Smith 8c9dcace0d ValueMapper: Resolve uniquing cycles more aggressively
As a follow-up to r244181, resolve uniquing cycles underneath distinct
nodes on the fly.  This prevents uniquing cycles in early operands from
affecting later operands.  It also removes an iteration through distinct
nodes' operands.

No real functional change here, just more prompt resolution of temporary
nodes.

llvm-svn: 244302
2015-08-07 00:44:55 +00:00
Duncan P. N. Exon Smith c9fdbdb78d ValueMapper: Pull out helper to resolve cycles, NFC
Pull out a helper for resolving uniquing cycles of `Metadata` to remove
the boiler-plate of downcasting to `MDNode`.

llvm-svn: 244301
2015-08-07 00:39:26 +00:00
Duncan P. N. Exon Smith 3115f75bf8 ValueMapper: Rotate distinct node remapping algorithm
Rotate the algorithm for remapping distinct nodes in order to simplify
how uniquing cycles get resolved.  This removes some of the recursion,
and, most importantly, exposes all uniquing cycles at the top-level.
Besides being a little more efficient -- temporary MDNodes won't live as
long -- the clearer logic should help protect against bugs like those
fixed in r243961 and r243976.

What are uniquing cycles?  Why do they present challenges when remapping
metadata?

    !0 = !{!1}
    !1 = !{!0}

!0 and !1 form a simple uniquing cycle.  When remapping from one
metadata graph to another, every uniquing cycle gets "duplicated"
through a dance:

    !0-temp = !{!1?}     ; map(!0): clone !0, VM[!0] = !0-temp
    !1-temp = !{!0?}     ; ..map(!1): clone !1, VM[!1] = !1-temp
    !1-temp = !{!0-temp} ; ..map(!1): remap !1's operands
    !2      = !{!0-temp} ; ..map(!1): uniquify: !1-temp => !2
    !0-temp = !{!2}      ; map(!0): remap !0's operands
    !3      = !{!2}      ; map(!0): uniquify: !0-temp => !3

    ; Result
    !2 = !{!3}
    !3 = !{!2}

(In the two "uniquify" steps above, the operands of !X-temp are compared
to the operands of !X.  If they're the same, then !X-temp gets RAUW'ed
to !X; if they're different, then !X-temp is promoted to a new unique
node.  The latter case always hits in for uniquing cycles, so we
duplicate all the nodes involved.)

Why is this a problem?  Uniquable Metadata nodes that have temporary
node as transitive operands keep RAUW support until the temporary nodes
get finalized.  With non-cycles, this happens automatically: when a
uniquable node's count of unresolved operands drops to zero, it
immediately sheds its own RAUW support (possibly triggering the same in
any node that references it).  However, uniquing cycles create a
reference cycle, and uniqued nodes that transitively reference a
uniquing cycle are "stuck" in an unresolved state until someone calls
`MDNode::resolveCycles()` on a node in the unresolved subgraph.

Distinct nodes should help here (and mostly do): since they aren't
uniqued anywhere, they are guaranteed not to be RAUW'ed.  They
effectively form a barrier between uniqued nodes, breaking some uniquing
cycles, and shielding uniqued nodes from uniquing cycles.

Unfortunately, with this barrier in place, the unresolved subgraph(s)
can be disjoint from the top-level node.  The mapping algorithm needs to
find at least one representative from each disjoint subgraph.  But which
nodes are *stuck*, and which will get resolved automatically?  And which
nodes are in the unresolved subgraph?  The old logic was conservative.

This commit rotates the logic for distinct nodes, so that we have access
to unresolved nodes at the top-level call to `llvm::MapMetadata()`.
Each time we return to the top-level, we know that all temporaries have
been RAUW'ed away.  Here, it's safe (and necessary) to call
`resolveCycles()` immediately on unresolved operands.

This should also perform better than the old algorithm.  The recursion
stack is shorter, temporary nodes don't live as long, and there are
fewer tracking references to unresolved nodes.  As the debug info graph
introduces more 'distinct' nodes, remapping should incrementally get
cheaper and cheaper.

Aside from possible performance improvements (and reduced cruft in the
`LLVMContext`), there should be no functionality change here.

llvm-svn: 244181
2015-08-05 23:52:42 +00:00
Duncan P. N. Exon Smith 2705097e47 ValueMapper: Simplify remap() helper function, NFC
Rename `remap()` to `remapOperands()`, and restrict its contract to
remapping operands.  Previously, it also called `mapToMetadata()`, but
this logic is hard to reason about externally.  In particular, this
refactors `mapUniquedNode()` to avoid redundant mapping calls, taking
advantage of the RAUWs that are already in place.

llvm-svn: 244168
2015-08-05 23:22:34 +00:00
Duncan P. N. Exon Smith 1de9ccb472 Fix 80-column
llvm-svn: 243977
2015-08-04 13:24:26 +00:00
Duncan P. N. Exon Smith 5ed90c0278 Linker: Fix ASan failure from r243961
r243883 and r243961 made a use-after-free far more likely:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/6041/steps/check-llvm%20asan/logs/stdio

Unresolved nodes get inserted into the `Cycles` array.  If they later
get resolved through RAUW, we need to update the reference.  It's
interesting that this never hit before (maybe an asan-ified clang
bootstrap with `-flto -g` would have hit it, but I admit I haven't tried
anything quite that crazy).

llvm-svn: 243976
2015-08-04 13:23:30 +00:00