align 64-bit integers on 32-bit platforms

[Daniel Theophanes]

I'm interested in in fixing https://github.com/golang/go/issues/599 which is to align 64-bit integers on 32-bit platforms. From first glance it looks like it might be a simple change to "cmd/compile/internal/gc/align.go" where the Field.Offset field gets assigned. But I'm either wrong on that or I haven't pushed the right buttons because the lights light up all wrong when I try.

But first, is this a desirable change? Probably quite a bit of non-"sync/atomic" variables will be given padding to them. Should 8 byte alignment be done to variables with a "//go:align8" or similar?

If this is a desirable change I would love to have a few pointers in the right direction.

Thanks, -Daniel

[minux]

Increasing the alignment has profound effects on abi.

For example, gcc doesn't align 64-bit integer to 8-byte either on 32-bit systems,

so this struct:

        struct T { int a; long long b; };

will no longer be representable in Go on 32-bit systems if Go aligns 64-bit int

to 64-bit.

I think the issue #599 is more about stack/data alignment, which is different

from field alignment. The cited performance concern for 64-bit alignment is

no longer true for recent Intel processors where unaligned moves don't have

much performance penalty anymore.

I also don't like introducing more magic comments.

The only major problem of the current 32-bit alignment on 64-bit types is

sync/atomic, but I think that's not a big problem. If you're going to use low

level atomic operations, you are expected to know the hardware well and

plan the structure layouts accordingly.

[Daniel Theophanes]

That's fine with me, but then we should update the docs and remove the BUG section to a notice.

[minux]

On Sun, Sep 25, 2016 at 1:11 AM, Daniel Theophanes <kard...@gmail.com> wrote:

That's fine with me, but then we should update the docs and remove the BUG section to a notice.

I never think that is a bug of Go. It's more of a unfortunate result from

Go's design that doesn't allow the user the specify custom alignment

for a field. But IMHO it's not a bug we intend to fix.

[Daniel Theophanes]

Then let's close the issue and change the "sync/atomic" BUG docs. That would make other conversations with other projects easier.

[minux]

On Sun, Sep 25, 2016 at 1:27 AM, Daniel Theophanes <kard...@gmail.com> wrote:

Then let's close the issue and change the "sync/atomic" BUG docs. That would make other conversations with other projects easier.

I think one of the reason it's collected under the Bugs section is that

the default godoc -notes flag is "BUG" only, so that's the only section

to highlight such notices.

I'm fine with putting such information in a NOTE section, but then it

won't be shown by godoc by default.

I suggest that we put it into a NOTE section and modify godoc to show

both: -notes 'NOTE|BUG'.

[Dave Cheney]

TBH, not doing anything sounds like the best option. The bug isn't
going to be fixed any time soon, and modifying godoc to show something
that was moved into a section which is not shown by default sounds
like work for the sake of generating heat through friction.

> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Austin Clements]

On Sun, Sep 25, 2016 at 1:07 AM, minux <mi...@golang.org> wrote:

On Sun, Sep 25, 2016 at 12:52 AM, Daniel Theophanes <kard...@gmail.com> wrote:

I'm interested in in fixing https://github.com/golang/go/issues/599 which is to align 64-bit integers on 32-bit platforms. From first glance it looks like it might be a simple change to "cmd/compile/internal/gc/align.go" where the Field.Offset field gets assigned. But I'm either wrong on that or I haven't pushed the right buttons because the lights light up all wrong when I try.

But first, is this a desirable change? Probably quite a bit of non-"sync/atomic" variables will be given padding to them. Should 8 byte alignment be done to variables with a "//go:align8" or similar?

If this is a desirable change I would love to have a few pointers in the right direction.

Increasing the alignment has profound effects on abi.

For example, gcc doesn't align 64-bit integer to 8-byte either on 32-bit systems,

so this struct:

        struct T { int a; long long b; };

will no longer be representable in Go on 32-bit systems if Go aligns 64-bit int

to 64-bit.

This is a concern for cgo, but cgo already cooperates closely with the runtime and we can certainly make it cooperate with the compiler to generate the struct layouts it needs.

I think the issue #599 is more about stack/data alignment, which is different

from field alignment. The cited performance concern for 64-bit alignment is

no longer true for recent Intel processors where unaligned moves don't have

much performance penalty anymore.

I also don't like introducing more magic comments.

The only major problem of the current 32-bit alignment on 64-bit types is

sync/atomic, but I think that's not a big problem. If you're going to use low

level atomic operations, you are expected to know the hardware well and

plan the structure layouts accordingly.

I see this as a language specification problem. The Go language spec says nothing about structure layouts, which sync/atomic cannot be used without depending on unspecified behavior.

It means it's easy to write code using sync/atomic that is non-portable and will panic at run time if you attempt to run it on a 32-bit machine.

It's also a recurring (and annoying) problem in the runtime.