Re: [PATCH, AARCH64] make stdarg functions work with +nofp

[James Greenhalgh <james.greenhalgh@arm.com>]

On Tue, Jun 02, 2015 at 11:38:29AM +0100, Kyrill Tkachov wrote:
> Hi James, Jim,
> 
> On 02/06/15 10:42, James Greenhalgh wrote:
> > On Sat, May 23, 2015 at 12:24:00AM +0100, Jim Wilson wrote:
> >> The compiler currently ICEs when compiling a stdarg function with
> >> +nofp, as reported in PR 66258.
> >>
> >> The aarch64.md file disables FP instructions using TARGET_FLOAT, which
> >> supports both -mgeneral-regs-only and +nofp.  But there is code in
> >> aarch64.c that checks TARGET_GENERAL_REGS_ONLY.  This results in FP
> >> instructions when using +nofp,  The aarch64.c code needs to use
> >> TARGET_FLOAT instead like the md file already does.
> >>
> >> I can't meaningfully test this with a bootstrap, since the patch has
> >> no effect unless I bootstrap with +nofp, and that will fail as gcc
> >> contains floating point code.
> >>
> >> The testsuite already has multiple stdarg tests, so there is no need
> >> for another one.
> >>
> >> I tested this by verifying I get the same results for some simple
> >> testcasess with and without the patch, with and without using
> >> -mgeneral-regs-only and -mcpu=cortex-a53+nofp.
> > This patch doesn't quite look right to me. The cases you change seem
> > like they should be (TARGET_FLOAT || TARGET_SIMD), rather than just
> > TARGET_FLOAT. In an armv8-a+nofp environment, you still have access to the
> > SIMD registers and instructions (reading between the lines on the bug
> > report, this is almost certainly not what is intended in Grub!).
> 
> I don't think that's quite right. TARGET_SIMD *always* implies TARGET_FP as
> it is a superset of that functionality.
> 
> For the precise relations of them look in aarch64-option-extensions.def.
> Turning off fp with +nofp (or -mgeneral-regs-only) always turns off simd
> while turning off simd with +nosimd doesn't turn off fp.

Right, understood. I had incorrectly thought we had kept them as fully
distinct options to disable parts of the ARMv8-A instruction set.

In which case, Jim, your patch is OK. Sorry for my initial confusion.

I think I saw a patch kicking around internally to improve the
documentation in this area, Alan - was that yours?

Thanks,
James