[PATCH] [AArch64] Make FP instructions optional

[Bernie Ogden]

Hi Tim,

You've convinced me :)

Specific responses in-line below.

> -----Original Message-----
> From: Tim Northover [mailto:t.p.northover at gmail.com]
> Sent: 29 October 2013 16:18
> To: Bernard Ogden
> Cc: reviews+D2052+public+9dd2881e9d28816d at llvm-reviews.chandlerc.com;
> Amara Emerson; llvm-commits
> Subject: Re: [PATCH] [AArch64] Make FP instructions optional
> 
> > 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).

A1.5 - though to my mind the language isn't as explicit as it could be.
'Specialised markets' presumably have to define their own way of passing
floats, if they need it.

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

Fair enough - there's no advantage to _not_ specifying the dependency. So
your request for it just reflects the present reality, which happens to be
the reality in the ARM backend too. My view on the ARM side is that it's not
worth removing 'NEON implies float' until a concrete case for it arises.
That day may well never come.

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

I guess that float-without-neon loons are more likely than
neon-without-float ones, and you can handle that with the dependency you
wanted. And neither species of loon is permitted by the current ARM-ARM.