https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
--- Comment #4 from Stefan Schulze Frielinghaus <stefansf at linux dot ibm.com>
---
For sparc we already see some sort of pre-optimization which "breaks" the new
test cases. For example, for test cmp-mem-const-1.c we have prior combine:
(insn 14 13 41 2 (set (reg:SI 117)
(ior:SI (reg:SI 118)
(const_int 1023 [0x3ff]))) "cmp-mem-const-1.c":10:13 307 {iorsi3}
(expr_list:REG_DEAD (reg:SI 118)
(expr_list:REG_EQUAL (const_int 1073741823 [0x3fffffff])
(nil))))
(insn 41 14 42 2 (set (reg:CC 100 %icc)
(compare:CC (reg:SI 117)
(reg:SI 116 [ *x_2(D) ]))) "cmp-mem-const-1.c":10:13 1
{*cmpsi_insn}
(expr_list:REG_DEAD (reg:SI 117)
(expr_list:REG_DEAD (reg:SI 116 [ *x_2(D) ])
(nil))))
where the 64-bit constant 0x3fffffffffffffff already got chopped into a 32-bit
constant 0x3fffffff. Thus in combine we only see
narrow comparison from mode SI to QI: (MEM leu 0x3fffffff) to (MEM leu 0x3f)
whereas I have been pretty strict in the new tests and demanded to see a 64-bit
constant:
scan-rtl-dump "narrow comparison from mode DI to QI" "combine"
Thus one solution would be to not consider the source mode by using
scan-rtl-dump "narrow comparison from mode .I to QI" "combine"
This would solve test cases cmp-mem-const-{1,2,3,4}.c. For cmp-mem-const-{5,6}
we have that the pre-optimization already chopped the 64-bit constant into a
32-bit constant and thus leaves us with nothing to do here. I'm not entirely
sure how we handled such cases in the past. Though, one solution would be to
simply exclude sparc from this test:
/* { dg-do compile { target { lp64 } && ! target { sparc*-*-* } } } */
Would that be ok?
