On Wed, Jun 05, 2019 at 05:02:53PM -0600, Jeff Law wrote: > 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))])] > >> + "" > >> +) > > > > 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.
op0 := op1; CC := op0 cmp 0; That's a perfectly fine dependency I think? > 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. Yeah, let's see what is really going on :-) Segher
