[AARCH64] [PATCH 1/3] AArch64 Port

[Marcus Shawcroft]

On 25/05/12 15:18, Joseph S. Myers wrote:
> General question: I suppose you expect to submit patches soon for
> other toolchain components (such as binutils, GDB, glibc) and the
> Linux kernel, if you haven't done so yet?

There is work going on to get other components ready for community 
review.  I expect to see patches submitted over the next few months.

>> +The @code{__float128} type is supported on hppa HP-UX targets and ARM AArch64
>> +targets.
>
> I don't see any good reason to support it on AArch64, since it's the
> same as "long double" there.  (It's on PA HP-UX as a workaround for
> libquadmath requiring the type rather than being able to with with a
> type called either "long double" or "__float128" - libquadmath being

Ok, thanks for the explanation, we will drop __float128.

>> +@item -march=@var{name}
>> +@opindex march
>> +Specify the name of the target architecture, optionally suffixed by one or
>> +more feature modifiers. This option has the form
>> +@samp{-march=<arch>[+[no]<feature>]}, where the only value for @samp{<arch>}
>> +is @samp{armv8}, and the possible values for @samp{<feature>} are
>> +@samp{crypto}, @samp{fp}, @samp{simd}.
>
> It's unfortunate that you've chosen this complicated syntax that means
> the generic support for enumerated option arguments cannot be used
> (and so --help information cannot list supported CPUs and features).
> A simpler syntax where -march takes just an architecture name and
> features have separate options would seem better, and more in line
> with most other architectures supported by GCC.

I will respond to this comment separately.

>> +__extension__ static __inline int8x8_t __attribute__ ((__always_inline__))
>> +vneg_s8 (int8x8_t a)
>> +{
>> +  int8x8_t result;
>> +  __asm__ ("neg %0.8b,%1.8b"
>> +           : "=w"(result)
>> +           : "w"(a)
>> +           : /* No clobbers */);
>> +  return result;
>> +}

> I presume you've determined for each intrinsic represented as an asm
> that it cannot usefully be described using generic GNU C, GIMPLE or
> RTL - as an example, for this one, what are its semantics that generic
> internal representations cannot handle usefully?

We initially put together a simple asm based implementation of each 
intrinsic.  Subsequently we have replaced many of the intrinsics with 
GNU C implementations.  The vneg_* patterns are an oversight which will 
be fixed.

We have a long list of intrinsics which we want to move into RTL, only 
some of these have been moved so far.  However, that said, point noted 
that we can usefully exploit TARGET_FOLD_BUILTIN in preference to RTL.

> Wht are you using t-softfp-sfdf and t-softfp-excl when
> aarch64/t-softfp appears to override them completely?

Agreed, these are not needed.

> Are you really planning to support non-ELF for AArch64?  If no, leave
> out the conditionals.

We have no plans for non-ELF, the conditionals will be removed.

The remainder of your comments will be addressed with patches shortly.

Thank you for the feedback!

/Marcus