cmd/compile/internal/ssa: incorrect type width when folding widening ops

[pmur]

Go version

tip

Output of go env in your module/workspace:

GOARCH=ppc64le

What did you do?

Further exploration of lower rule improvements has uncovered problems when using a Value Type's size to determine whether to apply a rule.

E.g the rule in PPC64.rules:

(MOVWZreg y:(AND (MOVDconst [c]) _)) && uint64(c) <= 0xFFFFFFFF => y

And later in PPC64latelower.rules:

(AND <t> x:(MOVDconst [m]) n) && t.Size() == 4 && isPPC64WordRotateMask(m) => (RLWINM [encodePPC64RotateMask(0,m,32)] n)

If m is the value 0xF000000F or a similar wrapping mask on PPC64, the upper 32 bits of the value are not always 0. I think this only affects rules which use RLWINM and RLWNM. I believe they are the only GPR opcodes on PPC64 which have this behavior.

What did you see happen?

The latelower rule is triggered in cases where the result is expected to be wider than the assigned type

What did you expect to see?

The Type of the result in lower should reflected the widened type.

[gabyhelp]

Similar Issues

• cmd/compile: PPC64 folds (MOVWZreg (RLWINM x)) incorrectly in some cases  #67844

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[pmur]

I suspect this is not causing problems today. 32 bit constants are sign extended, and thus any wrapping mask would produce a negative int32 constant, which prevents the AND rule above from running for such constants.

[gopherbot]

Change https://go.dev/cl/600817 mentions this issue: cmd/compile/internal/ssa: on PPC64, propogate larger type when folding widening ops