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
