[AARCH64] [PATCH 1/3] AArch64 Port

[Joseph S. Myers]

On Fri, 25 May 2012, Marcus Shawcroft wrote:

> 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.

I think the order of preference is roughly:

* Generic GNU C code.  For example, I saw you had addition intrinsics that 
just used "+" on the vector types.  This is the best approach for anything 
that can be represented like that in GNU C.  This includes any cases where 
the generic GNU C way of doing something is with a generic __builtin (for 
example, if the operation can naturally be defined in terms of 
__builtin_shuffle then you should do that).

* Architecture-specific built-in functions that fold to produce GENERIC / 
GIMPLE codes with architecture-independent semantics.  (But if several 
architectures have the same vector operation, it may be better to define 
an architecture-independent built-in function for it - though that then 
needs generic fallback support for architectures without the operation.)

* Architecture-specific built-in functions that produce RTL with 
architecture-independent semantics.

* Architecture-specific built-in functions that produce UNSPEC RTL.

* Inline asm.

And, inline functions will generally be preferred over macros, but it's 
possible there are cases (e.g. if the intrinsic is defined to take an 
lvalue argument and modify it) that can't be directly represented in C 
inline functions.

-- 
Joseph S. Myers
joseph@codesourcery.com