14 Commits

Author SHA1 Message Date
Duncan P. N. Exon Smith
4cd20e7e7d 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266258 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-13 22:54:01 +00:00
Duncan P. N. Exon Smith
81361659c5 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265828 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-08 18:49:36 +00:00
Duncan P. N. Exon Smith
ae29a03172 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265827 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-08 18:47:02 +00:00
Duncan P. N. Exon Smith
41e362dd89 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265768 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-08 03:13:22 +00:00
Duncan P. N. Exon Smith
50c7f32d75 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265765 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-08 00:56:21 +00:00
Duncan P. N. Exon Smith
698c0a7097 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265759 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-08 00:33:44 +00:00
Duncan P. N. Exon Smith
fcdd17bc64 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265637 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-07 02:10:50 +00:00
Duncan P. N. Exon Smith
5c7a97c89b 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265633 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-07 01:22:45 +00:00
Duncan P. N. Exon Smith
a10355896b 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265631 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-07 01:08:39 +00:00
Duncan P. N. Exon Smith
15121b5f36 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265456 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-05 20:23:21 +00:00
Duncan P. N. Exon Smith
eeb2c7e32c 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265228 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-02 17:04:38 +00:00
Duncan P. N. Exon Smith
ec78cb05a0 Document end of anonymous namespaces, NFC
Prevent clang-format from deleting the preceding newline.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265227 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-02 16:45:51 +00:00
Duncan P. N. Exon Smith
268a755585 Linker: Move distinct MDNodes instead of cloning
Instead of cloning distinct `MDNode`s when linking in a module, just
move them over.  The module linker destroys the source module, so the
old node would otherwise just be leaked on the context.  Create the new
node in place.  This also reduces the number of cloned uniqued nodes
(since it's less likely their operands have changed).

This mapping strategy is only correct when we're discarding the source,
so the linker turns it on via a ValueMapper flag, `RF_MoveDistinctMDs`.

There's nothing observable in terms of `llvm-link` output here: the
linked module should be semantically identical.

I'll be adding more 'distinct' nodes to the debug info metadata graph in
order to break uniquing cycles, so the benefits of this will partly come
in future commits.  However, we should get some gains immediately, since
we have a fair number of 'distinct' `DILocation`s being linked in.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243883 91177308-0d34-0410-b5e6-96231b3b80d8
2015-08-03 17:09:38 +00:00
Duncan P. N. Exon Smith
ed1d6bdfbd MapMetadata: Allow unresolved metadata if it won't change
Allow unresolved nodes through the `MapMetadata()` if
`RF_NoModuleLevelChanges`, since there's no remapping to do anyway.

This fixes PR22929.  I'll add a clang test as a follow-up.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232449 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-17 01:14:40 +00:00