On 6/2/19 6:28 AM, Segher Boessenkool wrote: > On Sat, Jun 01, 2019 at 11:41:30PM +0000, Fredrik Hederstierna wrote: >> +(define_peephole2 >> + [(set (match_operand:SI 0 "arm_general_register_operand" "") >> + (match_operand:SI 1 "arm_general_register_operand" "")) >> + (set (reg:CC CC_REGNUM) >> + (compare:CC (match_dup 0) (const_int 0)))] >> + "TARGET_ARM" >> + [(parallel [(set (reg:CC CC_REGNUM) (compare:CC (match_dup 1) (const_int >> 0))) >> + (set (match_dup 0) (match_dup 1))])] >> + "" >> +) > > Hi Fredrik, > > Do you have a testcase for this? I wonder if it would be better handled > during combine, and what that then tried; or perhaps these opportunities > are created later, making a peephole a more attractive solution. We have two independent insns with no output/true dependency between them. So there's really not anything for combine to do here.
What is more interesting to me is whether or not this could be handled by compare-elim and a define_insn rather than a define_peephole2. THe existing pattern and the new one both seem well suited for compare-elim. I do think a testcase is warranted here. Fredrik, if you could reduce one from CSiBE that might be appropriate. jeff
