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.
Cheers,
Kyrill
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
