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