mirror of
https://github.com/RPCSX/llvm.git
synced 2024-11-30 23:20:54 +00:00
29fa04dd53
Since forward references for uniqued node operands are expensive (and
those for distinct node operands are cheap due to
DistinctMDOperandPlaceholder), minimize forward references in uniqued
node operands.
Moreover, guarantee that when a cycle is broken by a distinct node, none
of the uniqued nodes have any forward references. In
ValueEnumerator::EnumerateMetadata, enumerate uniqued node subgraphs
first, delaying distinct nodes until all uniqued nodes have been
handled. This guarantees that uniqued nodes only have forward
references when there is a uniquing cycle (since r267276 changed
ValueEnumerator::organizeMetadata to partition distinct nodes in front
of uniqued nodes as a post-pass).
Note that a single uniqued subgraph can hit multiple distinct nodes at
its leaves. Ideally these would themselves be emitted in post-order,
but this commit doesn't attempt that; I think it requires an extra pass
through the edges, which I'm not convinced is worth it (since
DistinctMDOperandPlaceholder makes forward references quite cheap
between distinct nodes).
I've added two testcases:
- test/Bitcode/mdnodes-distinct-in-post-order.ll is just like
test/Bitcode/mdnodes-in-post-order.ll, except with distinct nodes
instead of uniqued ones. This confirms that, in the absence of
uniqued nodes, distinct nodes are still emitted in post-order.
- test/Bitcode/mdnodes-distinct-nodes-break-cycles.ll is the minimal
example where a naive post-order traversal would cause one uniqued
node to forward-reference another. IOW, it's the motivating test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267278 91177308-0d34-0410-b5e6-96231b3b80d8
25 lines
743 B
LLVM
25 lines
743 B
LLVM
; RUN: llvm-as <%s | llvm-bcanalyzer -dump | FileCheck %s
|
|
; Check that distinct nodes are emitted in post-order to avoid unnecessary
|
|
; forward references.
|
|
|
|
; Nodes in this testcase are numbered to match how they are referenced in
|
|
; bitcode. !3 is referenced as opN=3.
|
|
|
|
; The leafs should come first (in either order).
|
|
; CHECK: <DISTINCT_NODE/>
|
|
; CHECK-NEXT: <DISTINCT_NODE/>
|
|
!1 = distinct !{}
|
|
!2 = distinct !{}
|
|
|
|
; CHECK-NEXT: <DISTINCT_NODE op0=1 op1=2/>
|
|
!3 = distinct !{!1, !2}
|
|
|
|
; CHECK-NEXT: <DISTINCT_NODE op0=1 op1=3 op2=2/>
|
|
!4 = distinct !{!1, !3, !2}
|
|
|
|
; Note: named metadata nodes are not cannot reference null so their operands
|
|
; are numbered off-by-one.
|
|
; CHECK-NEXT: <NAME
|
|
; CHECK-NEXT: <NAMED_NODE op0=3/>
|
|
!named = !{!4}
|