Align atomics on ARM32

[xacrimon]

Fixes #11106 (comment)

Needs backport to v8 and v9

[Tener]

@xacrimon @espadolini oops, looks like my review wasn't needed after all. Feel free to ignore my approval :-)

[zmb3]

Making these pointers is kind of cheating. Why not rearrange the fields to ensure alignment?

[espadolini]

Making these pointers is kind of cheating. Why not rearrange the fields to ensure alignment?

https://cs.opensource.google/go/go/+/refs/tags/go1.18:src/sync/waitgroup.go;l=23-30

[xacrimon]

@zmb3 Go's spec nor any official docs guarantee that multiple fields types like that will work as far as I am aware. The only guarantee given is that the first field is 64-bit aligned on ARM32 for an allocated struct or type. This is the de-facto way from what I've seen to accomplish this. Even if this somehow works currently, I don't put a lot of trust into the Go compatability guarantees either and I wouldn't expect that to continue working in the future.

[xacrimon]

On second thought, we could probably get away with not aligning the 32 bit counters and hope that this doesn't break. I do know that it may be required in some cases on some chips but this probably isn't something we should support as it's not ARMv7 compliant anyway.

[xacrimon]

We do use the allocation pattern in other places. I will post a PR soon since I did just get some ideas for cleaning that up.

[zmb3]

The only guarantee given is that the first field is 64-bit aligned on ARM32 for an allocated struct or type

Right, and if you have multiple 64-bit fields, and you put them together, they'll all be aligned.

This LGTM as-is now.

[xacrimon]

The only guarantee given is that the first field is 64-bit aligned on ARM32 for an allocated struct or type

Right, and if you have multiple 64-bit fields, and you put them together, they'll all be aligned.

This LGTM as-is now.

I'm not so sure this is guaranteed (at least I couldn't find it documented in the spec or as a part of the stdlib docs) but it doesn't matter for this PR.