[dev.regabi] cmd/compile: swap inlining order of if then vs else blocks

The upcoming general iterators will process nodes in
source code order, meaning that the "then" block comes
before the "else" block. But for an if node, "then" is Body
while "else" is Rlist, and the inliner processes Rlist first.

The order of processing changes the order of inlining decisions,
which can affect which functions are inlined, but in general
won't affect much. (It's not like we know that we should prefer
to inline functions in else bodies over then bodies.)

Swapping these is not safe for toolstash -cmp.
Doing it in a separate CL lets the upcoming CLs all be toolstash-safe.

Change-Id: Id16172849239b0564930d2bbff1260ad6d03d5ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/275308
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This commit is contained in:
Russ Cox 2020-12-03 15:40:46 -05:00
parent 84cb51d7d7
commit 99ecfcae31

View File

@ -638,6 +638,14 @@ func inlnode(n ir.Node, maxCost int32, inlMap map[*ir.Func]bool) ir.Node {
}
}
inlnodelist(n.Body(), maxCost, inlMap)
s = n.Body().Slice()
for i, n1 := range s {
if n1.Op() == ir.OINLCALL {
s[i] = inlconv2stmt(n1)
}
}
inlnodelist(n.Rlist(), maxCost, inlMap)
if n.Op() == ir.OAS2FUNC && n.Rlist().First().Op() == ir.OINLCALL {
@ -658,14 +666,6 @@ func inlnode(n ir.Node, maxCost int32, inlMap map[*ir.Func]bool) ir.Node {
}
}
inlnodelist(n.Body(), maxCost, inlMap)
s = n.Body().Slice()
for i, n1 := range s {
if n1.Op() == ir.OINLCALL {
s[i] = inlconv2stmt(n1)
}
}
// with all the branches out of the way, it is now time to
// transmogrify this node itself unless inhibited by the
// switch at the top of this function.