https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398
Xiong Hu XS Luo <luoxhu at cn dot ibm.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |luoxhu at cn dot ibm.com
--- Comment #2 from Xiong Hu XS Luo <luoxhu at cn dot ibm.com> ---
Sorry that I mistook to change the case pr72804.c: this case has no
relationship with the parameter -fno-inline-functions --param
max-inline-insns-single-O2=200. This test appears in category of "New tests
that FAIL (6 tests):".
Checked the test result history:
For Power9, it is failed since r268152 of Jan 22, 2019.
https://gcc.gnu.org/ml/gcc-testresults/2019-01/msg02232.html.
For Power 7, it starts to fail since r267319 of Dec 21, 2018.
https://gcc.gnu.org/ml/gcc-testresults/2018-12/msg02500.html
Peter added this case pr72804.c in r251153 of Aug 17, 2017 to generate better
code for -mvsx-timode. But it restrict the condition to !BYTES_BIG_ENDIAN and
!TARGET_P9_VECTOR:
+;; Peepholes to catch loads and stores for TImode if TImode landed in
+;; GPR registers on a little endian system.
+(define_peephole2
+ [(set (match_operand:VSX_TI 0 "int_reg_operand")
+ (rotate:VSX_TI (match_operand:VSX_TI 1 "memory_operand")
+ (const_int 64)))
+ (set (match_operand:VSX_TI 2 "int_reg_operand")
+ (rotate:VSX_TI (match_dup 0)
+ (const_int 64)))]
+ "!BYTES_BIG_ENDIAN && TARGET_VSX && TARGET_VSX_TIMODE && !TARGET_P9_VECTOR
+ && (rtx_equal_p (operands[0], operands[2])
+ || peep2_reg_dead_p (2, operands[0]))"
+ [(set (match_dup 2) (match_dup 1))])
I am not sure these failures are leaved for won't fix or need update the vsx.md
to generate better code?
On Power9, the expected code is:
0000000000000020 <bar>:
20: f8 20 84 7c not r4,r4
24: f8 28 a5 7c not r5,r5
28: 00 00 83 f8 std r4,0(r3)
2c: 08 00 a3 f8 std r5,8(r3)
30: 20 00 80 4e blr
But actual code is:
0000000000000020 <bar>:
20: 66 23 05 7c mtvsrdd vs0,r5,r4
24: 10 05 00 f0 xxlnor vs0,vs0,vs0
28: 05 00 03 f4 stxv vs0,0(r3)
2c: 20 00 80 4e blr
