Thanks Jeff. I think I locate where aarch64 performs the trick here.
1. In the .final we have rtl like (insn:TI 6 8 29 (set (reg:SF 32 v0) (const_double:SF -0.0 [-0x0.0p+0])) "/home/box/panli/gnu-toolchain/gcc/gcc/testsuite/gcc.dg/pr30957-1.c":31:7 79 {*movsf_aarch64} (nil)) 2. the movsf_aarch64 comes from the aarch64.md file similar to the below rtl. Aka, it will generate movi\t%0.2s, #0 if the aarch64_reg_or_fp_zero is true. 1640 (define_insn "*mov<mode>_aarch64" 1641 [(set (match_operand:SFD 0 "nonimmediate_operand") 1642 match_operand:SFD 1 "general_operand"))] 1643 "TARGET_FLOAT && (register_operand (operands[0], <MODE>mode) 1644 || aarch64_reg_or_fp_zero (operands[1], <MODE>mode))" 1645 {@ [ cons: =0 , 1 ; attrs: type , arch ] 1646 [ w , Y ; neon_move , simd ] movi\t%0.2s, #0 3. Then we will have aarch64_float_const_zero_rtx_p here, and the -0.0 input rtl will return true in line 10873 because of no-signed-zero is given. 10863 bool 10864 aarch64_float_const_zero_rtx_p (rtx x 10865 { 10866 /* 0.0 in Decimal Floating Point cannot be represented by #0 or 10867 zr as our callers expect, so no need to check the actual 10868 value if X is of Decimal Floating Point type. */ 10869 if (GET_MODE_CLASS (GET_MODE (x)) == MODE_DECIMAL_FLOAT) 10870 return false; 10871 10872 if (REAL_VALUE_MINUS_ZERO (*CONST_DOUBLE_REAL_VALUE (x))) 10873 return !HONOR_SIGNED_ZEROS (GET_MODE (x)); 10874 return real_equal (CONST_DOUBLE_REAL_VALUE (x), &dconst0); 10875 } I think that explain why we have +0.0 in aarch64 here. Pan -----Original Message----- From: Jeff Law <jeffreya...@gmail.com> Sent: Friday, December 29, 2023 9:04 AM To: Li, Pan2 <pan2...@intel.com>; gcc-patches@gcc.gnu.org Cc: juzhe.zh...@rivai.ai; Wang, Yanzhang <yanzhang.w...@intel.com>; kito.ch...@gmail.com; richard.guent...@gmail.com Subject: Re: [PATCH v2] RISC-V: XFAIL pr30957-1.c when loop vectorized with variable factor On 12/28/23 17:42, Li, Pan2 wrote: > Thanks Jeff for comments, and Happy new year! > >> 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)? > > Yeah, it surprise me too when debugging the foo function. But didn't dig into > it in previous as it may be unrelated to vectorize. > >> 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. > > Sure, will have a try for making the -0.0 happen in aarch64. I would first look at the .optimized dump, then I'd look at the .final dump alongside the resulting assembly for aarch64. I bet we're going to find that the aarch64 target internally converts -0.0 to 0.0 when we're not honoring signed zeros. jeff