On 12/26/23 02:34, pan2...@intel.com wrote:
From: Pan Li <pan2...@intel.com>
This patch would like to XFAIL the test case pr30957-1.c for the RVV when
build the elf with some configurations (list at the end of the log)
It will be vectorized during vect_transform_loop with a variable factor.
It won't benefit from unrolling/peeling and mark the loop->unroll as 1.
Of course, it will do nothing during unroll_loops when loop->unroll is 1.
The aarch64_sve may have the similar issue but it initialize the const
`0.0 / -5.0` in the test file to `+0.0` before pass to the function foo.
Then it will pass the execution test.
aarch64:
movi v0.2s, #0x0
stp x29, x30, [sp, #-16]!
mov w0, #0xa
mov x29, sp
bl 400280 <foo> <== s0 is +0.0
Unfortunately, the riscv initialize the the const `0.0 / -5.0` to the
`-0.0`, and then pass it to the function foo. Of course it the execution
test will fail.
riscv:
flw fa0,388(gp) # 1299c <__SDATA_BEGIN__+0x4>
addi sp,sp,-16
li a0,10
sd ra,8(sp)
jal 101fc <foo> <== fa0 is -0.0
After this patch the loops vectorized with a variable factor of the RVV
will be treated as XFAIL by the tree dump when riscv_v and
variable_vect_length.
The below configurations are validated as XFAIL for RV64.
Interesting. So I'd actually peel one more layer off this onion. Why
do the aarch64 and riscv targets generate different constants (0.0 vs
-0.0)?
Is it possible that the aarch64 is generating 0.0 when asked for -0.0
and -fno-signed-zeros is in effect? That's a valid thing to do when
-fno-signed-zeros is on. Look for HONOR_SIGNED_ZEROs in the aarch64
backend.
Jeff
