RFA: Darwin x86 alignment

RFA: Darwin x86 alignment

[Dale Johannesen]

On x86 currently the alignments of double and long long are linked:
they are either 4 or 8 depending on whether -malign-double is set.
This follows the documentation of -malign-double.  But it's wrong for
what we want the Darwin ABI to be:  the default should be that double
is 4 bytes and long long is 8 bytes.

So I can do that, but what should -malign-double do?
- Control double but not long long; add -malign-long-long (at least if
    somebody asks for it; probably it wouldn't be used)
- Have flags work as now:  -malign-double makes both 8, 
-mno-align-double
   makes both 4.  Problem with that is the default is neither of these, 
and
   this doesn't fit neatly into gcc's model of two-valued flags; it's 
also a bit
   tricky to implement for the same reason.
- something else?

thanks.

Re: RFA: Darwin x86 alignment

[Richard Henderson]

On Thu, Jul 21, 2005 at 04:56:01PM -0700, Dale Johannesen wrote:
> - Have flags work as now:  -malign-double makes both 8, 
> -mno-align-double
>   makes both 4.  Problem with that is the default is neither of these, 
> and
>   this doesn't fit neatly into gcc's model of two-valued flags; it's 
> also a bit
>   tricky to implement for the same reason.

Nah, you just remove it from target_flags, and control the two
new variables from ix86_handle_option.

Why do you want to make these sort of arbitrary changes to your
ABI?  I can't see what you win...


r~

Re: RFA: Darwin x86 alignment

[Dale Johannesen]

On Jul 21, 2005, at 5:00 PM, Richard Henderson wrote:

> On Thu, Jul 21, 2005 at 04:56:01PM -0700, Dale Johannesen wrote:
>> - Have flags work as now:  -malign-double makes both 8,
>> -mno-align-double
>>   makes both 4.  Problem with that is the default is neither of these,
>> and
>>   this doesn't fit neatly into gcc's model of two-valued flags; it's
>> also a bit
>>   tricky to implement for the same reason.
>
> Nah, you just remove it from target_flags, and control the two
> new variables from ix86_handle_option.

OK.  Think that's the better approach?

> Why do you want to make these sort of arbitrary changes to your
> ABI?  I can't see what you win...

The compiler people are not driving this.

Of course, 4-byte alignment subjects you to a penalty for misaligned
loads and stores, and 8-byte alignment subjects you to a size penalty
for extra holes.   People have been making measurements about the
issue and this is what they've come up with; I don't know details.
What I wrote isn't necessarily the final change, either.

Re: RFA: Darwin x86 alignment

[Richard Henderson]

On Thu, Jul 21, 2005 at 05:21:58PM -0700, Dale Johannesen wrote:
> >Nah, you just remove it from target_flags, and control the two
> >new variables from ix86_handle_option.
> 
> OK.  Think that's the better approach?

*shrug*  It's not horrible, I guess.  It preseves existing
semantics when people use the switch; not that I'm a large
fan of switches like this that bork the abi.

My preferred solution is that you don't allow non-compiler
people to invent an ABI.  ;-)


r~

Re: RFA: Darwin x86 alignment

[Mark Kettenis]

   From: Dale Johannesen <dalej@apple.com>
   Date: Thu, 21 Jul 2005 16:56:01 -0700

   On x86 currently the alignments of double and long long are linked:
   they are either 4 or 8 depending on whether -malign-double is set.
   This follows the documentation of -malign-double.  But it's wrong for
   what we want the Darwin ABI to be:  the default should be that double
   is 4 bytes and long long is 8 bytes.

I have a strong suspicion there is a reason why the two are linked,
and that that reason is FORTRAN.  A lot of FORTRAN code assumes
EQUIVALENCE of floating-point and integer types of equal size.  Such
code will in all likelyhood break if those types have different
alignment.  For x86 this means that int/float and long long/double
will have to have the same alignment.

If my suspicion is right, I hope this still can be changed.  Otherwise
I'm sure a lot of Apple's customers doing scientific computing will be
rather pissed off.

Mark

Re: RFA: Darwin x86 alignment

[Dale Johannesen]

On Jul 23, 2005, at 6:40 AM, Tobias Schlüter wrote:
>> I have a strong suspicion there is a reason why the two are linked,
>> and that that reason is FORTRAN.  A lot of FORTRAN code assumes
>> EQUIVALENCE of floating-point and integer types of equal size.  Such
>> code will in all likelyhood break if those types have different
>> alignment.  For x86 this means that int/float and long long/double
>> will have to have the same alignment.
>
> This might indeed be a problem, as the alignments not only have to be 
> the same
> if they appear in an equivalence, but also in arrays or when using the
> TRANSFER intrinsic.  Out of the types dicussed, the standard only 
> specifies
> this for default INTEGERs (=int in C) and default REALs (=float in C), 
> but
> users do expect this to consistently extend to bigger types, otherwise 
> they
> consider the compiler buggy instead of their code.

Thanks for bringing this up.  It's probably true that nobody has 
thought about Fortran,
but so far I'm not convinced it would actually be a problem.  Can 
somebody provide
an example that would break?

> More precisely, the standard says this: a scalar variable of a certain 
> type
> occupies a certain number of "storage units".  Default INTEGERs, and 
> REALs
> take one storage unit, default COMPLEX and DOUBlE PRECISION (= REAL*8 
> = double
> in C) take two storage units.  Finally, arrays of these types take a 
> sequence
> of contiguous storage units.

I know.  These rules aren't affected by target alignments, though, and 
I would
not expect the Fortran FE to be affected by alignments when doing 
layout.   If it is, why?
The compiler already has to deal with misaligned data in Fortran:

   INTEGER I(3)
   DOUBLE PRECISION A,B
   EQUIVALENCE (A,I(1)), (B,I(2))

not to mention the user-specified alignment extensions in C, so I 
wouldn't expect
the optimizers to break or anything like that.

Re: RFA: Darwin x86 alignment

[Tobias Schlüter]

Mark Kettenis wrote:
>    From: Dale Johannesen <dalej@apple.com>
>    Date: Thu, 21 Jul 2005 16:56:01 -0700
> 
>    On x86 currently the alignments of double and long long are linked:
>    they are either 4 or 8 depending on whether -malign-double is set.
>    This follows the documentation of -malign-double.  But it's wrong for
>    what we want the Darwin ABI to be:  the default should be that double
>    is 4 bytes and long long is 8 bytes.
> 
> I have a strong suspicion there is a reason why the two are linked,
> and that that reason is FORTRAN.  A lot of FORTRAN code assumes
> EQUIVALENCE of floating-point and integer types of equal size.  Such
> code will in all likelyhood break if those types have different
> alignment.  For x86 this means that int/float and long long/double
> will have to have the same alignment.

This might indeed be a problem, as the alignments not only have to be the same
if they appear in an equivalence, but also in arrays or when using the
TRANSFER intrinsic.  Out of the types dicussed, the standard only specifies
this for default INTEGERs (=int in C) and default REALs (=float in C), but
users do expect this to consistently extend to bigger types, otherwise they
consider the compiler buggy instead of their code.

More precisely, the standard says this: a scalar variable of a certain type
occupies a certain number of "storage units".  Default INTEGERs, and REALs
take one storage unit, default COMPLEX and DOUBlE PRECISION (= REAL*8 = double
in C) take two storage units.  Finally, arrays of these types take a sequence
of contiguous storage units.  Details can be found in section 14.6.3 of the
Fortran 95 standard.  These sequences of storage units can be equivalenced
(i.e. a certain overlap between the sequences is requested by the user.  This
is only allowed for variables of the same type, but the extension to different
types is common and widely used).  Furthermore the TRANSFER intrinsic can be
used to copy the binary representation of variable/array A into variable/array
B; it is therefore also sensitive to memory layout.

- Tobi