cmd/compile: regression on ppc64le bit operations

[randall77]

package main

import (
	"fmt"
	"unsafe"
)

type st = struct {
	F__ccgo0 uint64
}

var constreg = [1]int32{}

func SetBitFieldPtr64Int64(p uintptr, v int64, off int, mask uint64) {
	*(*uint64)(unsafe.Pointer(p)) = *(*uint64)(unsafe.Pointer(p))&^mask | uint64(v)<<off&mask
}

func f() {
	var nIndx int32
	nIndx = 0
	SetBitFieldPtr64Int64(next+0, constreg1[nIndx], 0, 0xffffff)
	SetBitFieldPtr64Int64(next+0, constreg1[nIndx], 24, 0xffffff000000)
}

var constreg1 = [1]int64{
	0: int64(0xFEFEFEFE),
}

var bp [16]byte
var next = uintptr(unsafe.Pointer(&bp))

func main() {
	f()
	fmt.Printf("|% x|\n", unsafe.Slice((*byte)(unsafe.Pointer(next)), unsafe.Sizeof(st{})))
	if uint32(int32(int64(*(*uint64)(unsafe.Pointer(next + 0))&0xffffff>>0)<<40>>40)) != uint32(0xFFFEFEFE) {
		panic("FAIL")
	}
	if uint32(int32(int64(*(*uint64)(unsafe.Pointer(next + 0))&0xffffff000000>>24)<<40>>40)) != uint32(0xFFFEFEFE) {
		panic("FAIL")
	}
}

This should pass, but fails on ppc64le since https://go-review.googlesource.com/c/go/+/622236

@pmur @golang/ppc64

[jkrishmys]

Hi @randall77 . Thanks for bringing this to notice. I executed with go1.23 and go 1.24.1 on Power10le, with a few printf statements added to function f () before and after setting SetBitField in the above code.

with go 1.23 I see

Before first Set: |00 00 00 00 00 00 00 00|
After first Set: |fe fe fe 00 00 00 00 00|
After Second Set: |fe fe fe fe fe fe 00 00|
|fe fe fe fe fe fe 00 00|

with go 1.24.1 I see

Before first Set: |00 00 00 00 00 00 00 00|
After first Set: |fe fe fe 00 00 00 00 00|
After Second Set: |fe fe fe fe 00 00 00 00|
|fe fe fe fe 00 00 00 00|
panic: FAIL

The discrepancy occurs after the second call to SetBitFieldPtr64Int64. Specifically, the higher bits (24-47) are not being set correctly due to memory alignment or padding issues. Will try to figure out the changes that has happened in https://go-review.googlesource.com/c/go/+/622236.

[jkrishmys]

Hi @randall77, update. On PowerPC, the RLWINM (Rotate Left Word Immediate then AND with Mask) instruction operates on 32-bit words, even on a 64-bit system. So due to updates in files PPC64.rules and rewrite.go https://go-review.googlesource.com/c/go/+/622236. , mask := mergePPC64RShiftMask(m, s, 64) or mask := -1 << s & m may result in bits being set above the 32-bit range (bit positions 32 to 63). By rejecting those masks,

// Reject if mask touches bits above 31
    if mask >> 32 != 0 {
        return 0
    }

in functions mergePPC64AndSrdi and mergePPC64AndSldi immediately after calculating mask, we were able to get the above example run without failure on ppc64le after successful build.

[pmur]

That isn't accurate. The mask only wraps if mb > me, and only those cases leave junk in the upper 32 bits. That shouldn't happen when converting (andi (srdi()).

The linked rules should only narrow existing masks. I suspect a rule is eliding a 32 to 64 bit zero-extension where it shouldn't. That should be easy to find given the small reproducer. You can look at the rlwinm/rlwnm instructions.

[jkrishmys]

Hi, Sorry for the delay—I've been away briefly due to personal reasons. I'm now resuming work on this and wanted to share updated insights. I feel the following rewrite rule in ppc64.rules is problematic in 64-bit contexts:

(ANDconst [m] (SRWconst x [s])) && mergePPC64AndSrwi(m, s) != 0 => (RLWINM [mergePPC64AndSrwi(m, s)] x)
This rule fuses a 32-bit right shift and mask into a single RLWINM instruction. While this is safe for 32-bit values, it becomes unsafe when the result is used in a 64-bit context. RLWINM only affects the lower 32 bits of a register, leaving the upper 32 bits undefined unless explicitly zeroed. If the result flows into 64-bit computations or memory stores, it may lead to incorrect behavior. Similar concerns apply to the following rules:

(AND (MOVDconst [m]) (SRWconst x [s])) && mergePPC64AndSrwi(m, s) != 0 => (RLWINM [mergePPC64AndSrwi(m, s)] x)
(ANDconst [m] (SLDconst x [s])) && mergePPC64AndSldi(m, s) != 0 => (RLWINM [mergePPC64AndSldi(m, s)] x)
(AND (MOVDconst [m]) (SLDconst x [s])) && mergePPC64AndSldi(m, s) != 0 => (RLWINM [mergePPC64AndSldi(m, s)] x)

In the SLD variants, the issue is more subtle. SLD shifts into higher bits, but RLWINM can only represent fields in the 0–31 range. If the original 64-bit semantics are preserved by the SSA graph, this transformation can truncate or corrupt the result unless followed by an explicit zero-extension (MOVWZreg or equivalent). I feel these rewrites should only be applied when the result is known to be consumed as a 32-bit value. Otherwise, they must be followed by an explicit zero/sign extension to ensure correctness in 64-bit contexts.

[randall77]

If that's the case, then you can do && v.Type.Size() <= 32 to ensure that no one is using the upper 32 bits.

[jkrishmys]

Thank you for the suggestion! I see the intent behind using v.Type.Size() <= 32 as a guard, and I agree that placing a type-size check here is the right approach to ensure the rewrite is only applied in safe contexts.

Just to clarify: in the Go compiler’s SSA backend, v.Type.Size() returns the size in bytes, if I haven't got it wrong ( So for a 32-bit type, v.Type.Size() is 4). I used the guard as follows:

v.Type.Size() <= 4

With &&v.Type.Size() <= 4 added, I got the above code run to pass, Will check if there are more rules related to RLWINM which may require this guard and then submit a patch.

[jkrishmys]

Also, for all "inner" RLWINM patterns (some examples listed below), where the rewrite applies inside a larger expression and the output type is not directly available, can we wrap the RLWINM in a MOVWZreg to ensure correctness when the result is used in 64-bit contexts (while adding a minor instruction overhead)?
(SRWconst (ANDconst [m] x) [s]) && mergePPC64AndSrwi(m>>uint(s),s) != 0 => (RLWINM[mergePPC64AndSrwi(m>>uint(s),s)] x)

(SRWconst (AND (MOVDconst [m]) x) [s]) && mergePPC64AndSrwi(m>>uint(s),s) != 0=> (RLWINM [mergePPC64AndSrwi(m>>uint(s),s)] x)

(SLDconst [l] (SRWconst [r] x)) && mergePPC64SldiSrw(l,r) != 0 => (RLWINM [mergePPC64SldiSrw(l,r)] x)

[randall77]

Right, sorry, v.Type.Size() is size in bytes, not bits.

Yes, you can wrap in MOVWZreg if needed.

I don't think you need to, though. The rules aren't rewriting the inner values, they are just dropping references to them. If other SSA Values are using those inner parts as arguments, they won't change.

You can get the type of inner expressions by binding a name to them. For instance:

(SRWconst a:(ANDconst [m] x) [s]) && a.Type.Size() <= 4 ...