Re: [RFC] Add aarch64 support for ada

[Tristan Gingold <gingold at adacore dot com>]

On 17 Apr 2014, at 16:50, Richard Henderson <rth@redhat.com> wrote:

> On 04/17/2014 02:00 AM, Tristan Gingold wrote:
>> 
>> On 16 Apr 2014, at 17:36, Richard Henderson <rth@redhat.com> wrote:
>> 
>>> On 04/16/2014 12:39 AM, Eric Botcazou wrote:
>>>>> The primary bit of rfc here is the hunk that applies to ada/types.h
>>>>> with respect to Fat_Pointer.  Given that the Ada type, as defined in
>>>>> s-stratt.ads, does not include alignment, I can't imagine why the C
>>>>> type should have it.
>>>> 
>>>> See gcc-interface/utils.c:finish_fat_pointer_type.
>>> 
>>> Ah hah.
>>> 
>>> /* Make sure we can put it into a register.  */
>>> if (STRICT_ALIGNMENT)
>>>   TYPE_ALIGN (record_type) = MIN (BIGGEST_ALIGNMENT, 2 * POINTER_SIZE);
>>> 
>>> AArch64 is not a STRICT_ALIGNMENT target, thus the mismatch.
>> 
>> As the align attribute in types.h is for the host, couldn't a configure test solve
>> this issue ?
> 
> I doubt it.  I'm not sure what kind of configure test you could write that
> would determine the setting of STRICT_ALIGNMENT, since even non-strict-align
> targets prefer to align data for performance reasons.  Be careful that the test
> couldn't be an execution test, lest you break host != build.

What about this compile-time check:

package Fatptralign is
   type String_Acc is access String;
   type Integer_acc is access Integer;

   pragma Compile_Time_Error
    (String_Acc'Alignment = 1 * Integer_Acc'Alignment,
     "Fat pointer are simply aligned");

   pragma Compile_Time_Error
    (String_Acc'Alignment = 2 * Integer_Acc'Alignment,
     "Fat pointer are doubly aligned");
end Fatptralign;


>> One of the most common Fat_Pointer is for strings, which aren't declared in any
>> source and is very commonly used.
>> 
>> OTOH, I think this optimization mostly targets sparc.
> 
> Indeed, 32-bit sparc wants 64-bit alignment for its ldd/std instructions.
> 
> Perhaps the better optimization (supposing it's really worth keeping)

That's a true question (worth keeping).  I think this also affects powerpc (as
an important target)

Eric ?

> is to
> DECL_ALIGN the static strings, rather than align the type?

[ Ada strings (and more generally Ada unconstrained array and Ada accesses to
  unconstrained arrays) are represented in GNAT by a fat pointer, ie a structure
  containing a pointer to the bounds and a pointer to the data.
  We are talking about the alignment of that structure. ]

> Presumably Ada strings are as with C string literals -- symbols private to the
> compilation unit which are normally passed by value.  Thus functions within the
> compilation unit would see the extra alignment of the data and be able to use
> ldd to load the pair.  On the receiving end being able to use std would remain
> a matter of luck.

I think this will dismiss most of the gain.  Fat pointers can be heavily used in
some applications, and be present in structures.  Gain with only private symbols
might be tiny.

Tristan.