A problem with aligment attribute
Jim Wilson
wilson@specifixinc.com
Thu Feb 5 19:38:00 GMT 2004
H. J. Lu wrote:
> void
> foo (int i, float128_type x)
> {
> if (((long) (&x.word0) & 15) != 0)
> abort ();
My first answer was nonsense. PARM_BOUNDARY is of course the minimum
alignment, not the maximum. Let me try this again.
You are asking for a feature here, 16-byte aligned args, which is not
part of the standard C language, and hence not part of standard ABIs.
We could support this, but we would need to design an ABI variant for
gcc and implement it. There are a number of possible pitfalls here.
We will need ABI changes for every target. There will likely be a long
period during which this feature works for some but not all targets.
The ABI extension design is unlikely to be rigorous enough on the first
attempt, resulting in later revisions that cause ABI incompatibilities.
The ABI implementation will be hard to test, because we can't compare it
against any other compiler's implementation, and thus there will likely
be bugs that result in later ABI incompatibilities when they are fixed.
Future revisions to the C language standard may prompt changes to the
standard ABI, and these changes may conflict with our ABI extensions,
resulting in ABI incompatibilities.
We need more than just changes to FUNCTION_ARG_* in each gcc back end.
We also need changes to varargs support for every target, changes to the
ABI compat testsuite, and changes to libffi support for every target,
and possibly also other changes I haven't thought of.
We need to consider whether this feature is worth the trouble it will
cause. I don't think it is.
However, we can make some useful simplifying assumptions here. If the
alignment is smaller or equal to BIGGEST_ALIGNMENT, then we can perhaps
make it work with minimal ABI changes. The x86 port does have biggest
alignment set to 128, so asking for 16-byte aligned parameter is not
unreasonable. And we already have 16-byte aligned parameters when an
SSE vector type is used. See contains_128bit_aligned_vector_p. This
could perhaps be extended to support your case.
This approach has pitfalls of its own though, sometimes an alignment
attribute will work and sometimes it won't, it depends on the amount of
alignment you are asking for, and the max alignments supported by the
target for parameters, and possibly also other factors. Writing
documentation that clearly explains this, and/or writing code to give
proper warnings may be difficult, so it isn't clear that this is
desirable either.
It is easier to just document that aligned attributes have no effect on
alignment of parameters.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
More information about the Gcc
mailing list