What version of Go are you using (go version)?
$ go version
tip
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
PPC64
What did you do?
Inspected generated code after CL #531425 to verify expected improvements. The purpose of this change was to avoid ANDCCconst if possible, which removed an instruction that set the flag unnecessarily.
What did you expect to see?
Same or better code than before my change.
What did you see instead?
I noticed that for some functions the NilCheck wasn't optimized, whereas before my change it was. When looking at the GOSSAFUNC output with this change, tighten was able to move a load into a different (successor) block but left the associated NilCheck in the original block. The later NilCheck elimination pass only eliminates the NilCheck if is in the same block as the load or store that uses the NilCheck address.
An example of this is found in internal/abi.(*Name).IsBlank.
Even though I discovered this difference after my change for PPC64, it seems like this is a general problem in tighten if loads or stores are moved to a different block when they had related NilChecks in their original block because then the NilChecks can't be optimized.
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)?PPC64
What did you do?
Inspected generated code after CL #531425 to verify expected improvements. The purpose of this change was to avoid ANDCCconst if possible, which removed an instruction that set the flag unnecessarily.
What did you expect to see?
Same or better code than before my change.
What did you see instead?
I noticed that for some functions the NilCheck wasn't optimized, whereas before my change it was. When looking at the GOSSAFUNC output with this change, tighten was able to move a load into a different (successor) block but left the associated NilCheck in the original block. The later NilCheck elimination pass only eliminates the NilCheck if is in the same block as the load or store that uses the NilCheck address.
An example of this is found in internal/abi.(*Name).IsBlank.
Even though I discovered this difference after my change for PPC64, it seems like this is a general problem in tighten if loads or stores are moved to a different block when they had related NilChecks in their original block because then the NilChecks can't be optimized.