This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Options of fixing biggest alignment in PR target/38736
"H.J. Lu" <hjl.tools@gmail.com> writes:
> For 4.4, we can apply my patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00367.html
>
> and update document with
>
> As in the preceding examples, you can explicitly specify the alignment
> (in bytes) that you wish the compiler to use for a given variable or
> structure field. Alternatively, you can leave out the alignment factor
> and just ask the compiler to align a variable or field to the maximum
> useful alignment for the target ABI you are compiling for. For
> example, you could write:
>
> @smallexample
> short array[3] __attribute__ ((aligned));
> @end smallexample
>
> Whenever you leave out the alignment factor in an @code{aligned} attribute
> specification, the compiler automatically sets the alignment for the declared
> variable or field to the largest alignment for the target ABI you are
> compiling for. Doing this can often make copy operations more efficient,
> because the compiler can use whatever instructions copy the biggest
> chunks of memory when performing copies to or from the variables or
> fields that you have aligned this way.
Shouldn't the docs say something about memory allocation? As in,
malloc should return memory aligned to that boundary?
For that matter, don't we have a problem on x86 GNU/Linux, where
malloc returns an 8-byte alignment but attribute((aligned)) is a 16
byte alignment?
>> any new __attribute ((aligned (XXX))) options?
>>
>
> I don't think we need new __attribute ((aligned (XXX))) options.
Are we sure we don't need __attribute__ ((aligned(max)))?
Ian