Recent combine change causing regressions

[Jeff Law]

On 5/13/19 8:38 AM, Segher Boessenkool wrote:
> On Mon, May 13, 2019 at 08:27:15AM -0600, Jeff Law wrote:
>> sh3-linux-gnu and sh3eb-linux-gnu:
> 
> I test sh2 and sh4, but not sh3 :-)
> 
>> Tests that now fail, but worked before (3 tests):
>>
>> gcc.target/sh/pr51244-11.c scan-assembler-not subc|and|bra
>> gcc.target/sh/pr51244-11.c scan-assembler-times bf\t0f 1
>> gcc.target/sh/pr51244-11.c scan-assembler-times bt\t0f 1
>>
>> Previously we'd match this pattern:
>>
>> (define_insn "*cset_zero"
>>   [(set (match_operand:SI 0 "arith_reg_dest" "=r")
>>         (if_then_else:SI (match_operand:SI 1 "cbranch_treg_value")
>>                          (match_operand:SI 2 "arith_reg_operand" "0")
>>                          (const_int 0)))]
>>   "TARGET_SH1 && TARGET_ZDCBRANCH"
>>
>> After your change we no longer try to do so.
>>
>> I really don't care about the SH port.  But isn't this really a symptom
>> of a larger problem.  Namely that by not generating if-then-else you've
>> hosed every target that implements conditional moves via if-then-else
>> constructs?
> 
> I tested on 30-something targets (all *-linux), and only mips64 regressed
> a little, everything else improved.  So the current tuning is better than
> what it was before.  No doubt it can be improved though!
> 
> This is only if-then-else for a single bit, fwiw.
So are other targets still generating conditional moves?  If so the fix
may ultimately be to rewrite that pattern in the SH backend.

> 
> I'll build some sh3-linux if I find a cycle or two.
Thanks.  It does reproduce with a cross. In fact, you just need the
compiler -- you don't need an assembler, binutils, headers, etc :-)

jeff