On 06/06/2019 00:46, Segher Boessenkool wrote: > 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?
But if op0 isn't dead after the second insn, combine won't consider it, right? Even though in this case the combination would be safe as we still produce op0. R. > >> 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 >
