Yes, as Keith said, the 16-byte alignment requirement of sp is for the size
of the entire stack, and there is no such requirement for a single variable
on the stack. We can access a single variable through sp+/-offset.
The code has already dealt with the overall alignment of sp. I tried to
remov
Ah, arm64.
That code jesper points to looks like the culprit.
The whole stack frame alignment should be handled separately from the
alignment of individual variables, so the total alignment needed shouldn't
matter.
Not sure why we do that. A small archaeology dive indicates this code dates
from
On Wed, Nov 4, 2020 at 9:36 AM eric...@arm.com wrote:
> I got it, the code is here
> https://github.com/golang/go/blob/633f9e206045176a12c301eb2c249c1c1d9a5d2e/src/cmd/compile/internal/gc/pgen.go#L186
> ,
> I don't know why the slot is required to be aligned at least 8 bytes on
> these architectu
I got it, the code is
here
https://github.com/golang/go/blob/633f9e206045176a12c301eb2c249c1c1d9a5d2e/src/cmd/compile/internal/gc/pgen.go#L186,
I don't know why the slot is required to be aligned at least 8 bytes on
these architectures. I will try to see if this requirement can be removed
on
Hi Keith, thank you for your response. Sorry I didn't say that I saw this
issue on linux/arm64. For your example above, the result on linux/arm64 is
like this:
go tool compile -S tmp.go
0x001c 00028 (spill.go:4) MOVD"".p(FP), R0
0x0020 00032 (spill.go:4) MOVH
It don't think it does. For instance, an int16 will be spilled to a 2-byte
slot in the stack frame.
Can you show us what you are seeing? This is what I tried:
package main
func f(p, q *int16) {
x := *p
y := *q
g()
*p = y
*q = x
}
func g()
go tool compile -S tmp.go
0x001d 00029 (tmp1.go:4) MOVQ
