[PATCH] ValueMapper: Rewrite Mapper::mapMetadata without recursion
Duncan P. N. Exon Smith via llvm-commits
llvm-commits at lists.llvm.org
Sun Apr 3 22:51:52 PDT 2016
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.
MapMetadata barely shows up in the profiles of llvm-link I've looked at
with the new algorithm.
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 somehow leaking (at least an opaque version
of) the "Mapper" context into the API, perhaps by sending a callback
function to materializeInitFor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ValueMapper-Rewrite-Mapper-mapMetadata-without-re-v1.patch
Type: application/octet-stream
Size: 21329 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160403/78dd8978/attachment.obj>
More information about the llvm-commits
mailing list