[PATCH] [AArch64] Make FP instructions optional

[Bernie Ogden]

On the software side, I note that CPACR permits NEON to be disabled, or both NEON and FP to be disabled. So my assertion that you should have a single attribute to model the architecture was wrong.

On the CPU implementation side, v7 had NEON and FP as independent options - although no-one has yet implemented an integer NEON core so far as I know. (And in LLVM's ARM backend, NEON (architecturally incorrectly) implies VFP.) In the released v8 ARM-ARM, FP and NEON are selected together - i.e. you have both or neither, so NEON is no longer just 'strongly encouraged'. It also expected that 'non-specialist' implementations will have FP & NEON.

But who knows what the future will hold? OK, if you take that argument to an extreme you'll never pin anything down, but in this case there is history for NEON and FP being independent. 

Perhaps I'm just being fussy, but if there's no practical advantage then why enforce the dependency? Keeping them independent at least gives some protection against code assuming that if NEON is avilable, FP is also available.

 
> -----Original Message-----
> From: Tim Northover [mailto:t.p.northover at gmail.com]
> Sent: 29 October 2013 15:22
> To: t.p.northover at gmail.com; Amara Emerson
> Cc: llvm-commits at cs.uiuc.edu; Bernard Ogden
> Subject: Re: [PATCH] [AArch64] Make FP instructions optional
> 
> 
>   Hi Bernie,
> 
>   > Is there enough advantage in NEON-implies-FP to outweigh the loss
> of flexibility?
> 
>   Well, it's almost certainly going to be a completely untested
>   combination. Other than that, I suppose not.
> 
>   > If you really want to model the architecture here then don't
>   > you need a single feature controlling both FP and NEON?
>   > The ARM-ARM today requires both or neither.
> 
>   I *think* the ARM ARM is referring to the ability to disable FP &
> NEON
>   (not independently, as you note) so that any attempt to execute them
>   will be UNDEFINED (e.g. to implement lazy context-switching).
> 
>   There's a separate issue of whether it's valid for a CPU to simply
> not
>   implement one of them, and if so which combinations are allowed and
>   where the line is drawn.
> 
>   My understanding (which is obviously out of date now) is that NEON
> was
>   strongly encouraged but not mandated, but that FP was part of the
> base
>   instruction-set. The NEON and basic instructions were always kept in
>   separate documents and so on. But for some reason the beta ARM ARM
>   doesn't annotate the variants right not.
> 
>   Is anything happening there?
> 
>   Cheers.
> 
>   Tim.
> 
> http://llvm-reviews.chandlerc.com/D2052