On Mon, 2019-05-13 at 09:38 -0500, 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. > > I'll build some sh3-linux if I find a cycle or two. >
Hmmm .. on SH3 TARGET_ZDCBRANCH should be off, afair. What would be the alternative now for the if-then-else? Cheers, Oleg
