PATCH: PR target/38736: [4.4 Regression] -mavx can change the ABI via BIGGEST_ALIGNMENT

Ian Lance Taylor iant@google.com
Wed Jan 7 20:13:00 GMT 2009


"H.J. Lu" <hjl.tools@gmail.com> writes:

> Index: gcc/doc/extend.texi
> ===================================================================
> --- gcc/doc/extend.texi	(revision 4884)
> +++ gcc/doc/extend.texi	(working copy)
> @@ -3697,9 +3697,8 @@ that forces the union to be double-word 
>  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 machine you are compiling for.  For
> -example, you could write:
> +and use the default alignment for the target machine you are compiling
> +for.  For example, you could write:
>  
>  @smallexample
>  short array[3] __attribute__ ((aligned));
> @@ -3707,11 +3706,11 @@ short array[3] __attribute__ ((aligned))
>  
>  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 which is ever used for any data
> -type on the target machine you are compiling for.  Doing this can often make
> +variable or field to the default alignment.  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.
> +instructions to copy the biggest chunks of memory aligned at the
> +default alignment when performing copies to or from the variables or
> +fields that you have aligned this way.

The phrase "default alignment" does not usefully describe what this is
for.  It's not even clear what it means.

I don't think the first paragraph above needs to change at all.

How about something like this for the second paragraph?  Other
opinions welcome.

    When you leave out the alignment factor in an @code{aligned}
    attribute specification, the compiler sets the alignment for the
    variable or field to the largest useful alignment on the target
    machine for which you are compiling.  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.

    When new instructions are added to a processor, they may cause the
    largest useful alignment to increase.  A compiled library should
    not rely on the precise effect of the @code{aligned} attribute
    with no alignment factor remaining the same across different
    compiler versions.  For example, if you expect to distribute a
    binary version of a library which will be linked with code
    compiled with future versions of GCC, be careful about putting
    something like this in a header file for users of the library:

    @smallexample
    struct s { char a; char buf[64] __attribute__ ((aligned)); };
    extern void f(struct s*);
    @end smallexample

    The precise offset of the field @code{buf} may change in different
    compiler versions.

The rest of your patch is OK, but please wait 48 hours to give the
frontend maintainers, or anybody else a chance to comment.

Thanks.

Ian



More information about the Gcc-patches mailing list