[PATCH] [AArch64] Make FP instructions optional

[Tim Northover]

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

Where's that stated? I'm sure at the start of the year FP was
mandatory and NEON was optional. GCC's (and Clang's) -mcpu options
reflected this dichotomy, as does the PCS (there's no mention of a
soft-float variant at all, for example).

> Perhaps I'm just being fussy, but if there's no practical
> advantage then why enforce the dependency?

Well, a non-broken compiler is a fairly big advantage.

> Keeping them independent at least gives some protection against
> code assuming that if NEON is avilable, FP is also available.

LLVM itself assumes that, or at least the AArch64 backend does:

declare void @bar(<2 x float>, <2 x float>)
define void @foo(<2 x float> %in) {
  call void @bar(<2 x float> undef, <2 x float> %in)
  ret void
}

$ llc -march=aarch64 -mattr=+neon,-fp-armv8 simple.ll

OK, so that's a fairly easily fixable issue (in copyPhysReg), but it
sprang almost immediately to mind. I'd bet there are far more just
waiting to come out and bite anyone that tries to use that
combination.

Actually, that combination makes a specification even more important:
is "fadd v0.2s, v0.2s, v0.2s" fp-armv8 or neon? I suspect the loons
who want no floating-point will want to omit it too, but who knows?

Cheers.

Tim.