On 08/29/2017 02:39 AM, Kyrill Tkachov wrote: >>> This scares combine away as x0 is used in insn 33 as well as the >>> comparison in insn 34. >>> I think the compare-elim pass can help us here. >> Is it the multiple use or the hard register that combine doesn't >> appreciate. The latter would definitely steer us towards compare-elim. > > It's the multiple use IIRC. OK. I can see a case where multiple use causes a problem as well. That non-combinable use at insn 33 could well be a problem for combining insn 7 and insn 34 from your sample RTL.
>> What about old style asms? Do you need to explicit punt those? I don't >> think they carry DF info. > > I think we want to bail out on those to be safe. How are they > represented in RTL? I think old style asms will be an insn with an ASM_INPUT as their pattern. New sytle asms (ie, with dataflow) would be an insn with ASM_OPERANDs as their pattern. > >> Don't you also have to verify that the inputs to ARITH_INSN are >> unchanged between ARITH_INSN and CMP_INSN? > > I don't think so. As long as there is no flag clobbering instructions > between them we should be ok. Right. It's really a matter of which direction you go. Working with your example: > > Consider: > r1 := r2 + r3 // arith_insn > r2 := r4 + r5 // arith_insn input modified before cmp_insn > cc := CMP r1 0 // cmp_insn combining the r1 := and the cc:= statements essentially means one is going to move across the r2 := statment. If the cc assignment moves, then you need to verify that cc and r1 are not changed. If the r1 assignment moves, then you need to verify that r2 and r3 are not changed. You're doing the former but I was thinking of the latter. >
