Comment 1:

I meant a magic comment in Go code.  But of course some sort of assembler support would
be required as well.

Comment 2 by rayneolivetti:

Indeed, that is what I intended to write. I'm sorry about the poor language.

Comment 3:

This is a big topic. I do not know what the right solution is here. Magic comments would
help with specific variables, but it is unclear to me what to do about fields in structs
and so on. This would somehow get mixed into the type system, whether implicitly or
explicitly, and it's not clear which way makes a smaller mess.

Labels changed: added priority-later, removed priority-triage.

Owner changed to @rsc.

Status changed to Thinking.

Comment 4:

I think the OP is only asking about alignment control in assembly files.
I agree that for Go it will be a much bigger problem.

Comment 5 by rayneolivetti:

Yes, I'm only hoping to see the support for this in assembly files (hence cmd/as, but
maybe I should simply have said [568]a/[568]l). Maybe it's better to file an issue for
the Go-side support?
This is such a basic feature that any assembler (other than Plan 9 assembler) I have
ever used (even ancient Zilog 80 assemblers!) has this feature. I have the impression
that at the time Plan 9 assembler was written, the authors didn't imagine that alignment
is a real issue and enforcing "native-alignment" (64-bits for amd64 for instance) as the
"one true alignment", without any options, is the best way to go.
In this age of SSE/AVX, such an assumption is no longer valid and causes performance
problems.

Comment 6:

I don't understand what it means to have alignment support only in assembly files.
Usually assembly functions operate on data allocated outside the assembly file.

Comment 7:

Labels changed: added go1.3maybe.

Comment 8 by rayneolivetti:

I'm not sure what this means, you can define your data in assembly or Go code.
A more specific example (taken from real production code) is be the mask data, that is
not passed as a parameter to the function.
Ideally, yes, it would be just perfect to have such support on Go side.
Would make everything much easier. Only assembly support is still okay, since it's
better than the current state (it's totally impossible to have any aligned data at all).
Additionally, assembly side support will be needed for a potential Go-side support
anyway.

Comment 9:

Labels changed: added release-none, removed go1.3maybe.

Comment 10:

Labels changed: added repo-main.