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

[James Greenhalgh]

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

Digging a bit deeper in to the ICE in PR66258, it seems to me that
the problematic pattern is "*movti_aarch64":

  (define_insn "*movti_aarch64"
    [(set (match_operand:TI 0
	   "nonimmediate_operand"  "=r, *w,r ,*w,r  ,Ump,Ump,*w,m")
	  (match_operand:TI 1
	   "aarch64_movti_operand" " rn,r ,*w,*w,Ump,r  ,Z  , m,*w"))]
    "(register_operand (operands[0], TImode)
      || aarch64_reg_or_zero (operands[1], TImode))"
    "@
     #
     #
     #
     orr\\t%0.16b, %1.16b, %1.16b
     ldp\\t%0, %H0, %1
     stp\\t%1, %H1, %0
     stp\\txzr, xzr, %0
     ldr\\t%q0, %1
     str\\t%q1, %0"
    [(set_attr "type" "multiple,f_mcr,f_mrc,neon_logic_q, \
	             load2,store2,store2,f_loadd,f_stored")
     (set_attr "length" "8,8,8,4,4,4,4,4,4")
     (set_attr "simd" "*,*,*,yes,*,*,*,*,*")
     (set_attr "fp" "*,*,*,*,*,*,*,yes,yes")]
  )

Note that the split alternatives are going to unconditionally create
and emit insns which require TARGET_FLOAT, but the fp attribute is
not set on those alternatives. Many of the TI mode split patterns
could be expressed as a umov from vector registers to general purpose
registers for a TARGET_SIMD target.

Have you investigated this approach at all?

Thanks,
James