Open nngffhj opened 1 year ago
CC @golang/compiler
CC @dr2chase in particular, who I think was recently looking into loop invariant hoisting. I think there's an open bug for loop invariant hoisting already, and IIUC (though I could be wrong) that optimization doesn't make a meaningful difference in real-world programs, only microbenchmarks. It might still be worth doing as it adds up, but I just wanted to add that context.
a.nd = 0
for n--; n >= 0; n-- {
a.d[a.nd] = buf[n]
a.nd++
}
Hoisting the a.nd
loads is tricky because the compiler currently doesn't do any alias analysis, so the write to a.d
could be one of the bytes of a.nd
. This is on the pretty easy end of alias analysis, though, as the same base pointer makes it pretty obvious. So maybe doable.
Some loop rotation might get you down to 1 load of a.nd
per iteration.
@randall77 Is there another issue out for this? I feel like we already have a redundant loads issue somewhere, though maybe this specific one is different.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I ran a redundant loads detecting tool on function strconv.FormatFloat().
What did you expect to see?
Redundant loads can be optimized by the compiler.
What did you see instead?
In function rightShift() in package strconv,
a.nd
is a loop invariant. But the compiler failed to put it in a register, resulting ina.nd
being loaded from memory repeatedly in each iteration.In function Assign() in package strconv,
a.nd
is loaded from memory twice in a single iteration.