Right way to represent flag-setting arithmetic instructions in MD files

Kyrill Tkachov kyrylo.tkachov@foss.arm.com
Mon Mar 13 09:53:00 GMT 2017


On 10/03/17 23:56, Segher Boessenkool wrote:
> On Fri, Mar 10, 2017 at 10:30:33AM +0000, Kyrill Tkachov wrote:
>> I'm trying to improve the cases where the result of the arithmetic
>> operation is used in multiple places besides the comparison.
>> For example:
>>          add     w0, w0, w1
>>          add     w1, w0, 2
>>          cmp     w0, 0
>>
>> Combine will not attempt to merge the first ADD and CMP because W0 is used
>> in the second ADD.
> So the LOG_LINK from the first instruction will point at the second,
> and combining the first and the third isn't considered (because the
> first and second insns don't combine).

Yeah, that's what I'm seeing

> combine doesn't try to combine all producer-consumer pairs, only
> producer with first consumer, because it would not often help and
> could easily take much more time.  On the other hand I'd love to get
> rid of the LOG_LINKS and use DF directly.

Are there any significant barriers to moving to DF?
I heard some other passes (e.g. LRA) are reluctant to use
DF because it's too slow.


> Note that combining the first and third insns in your example requires
> to put the combined insns in the place of the first insn, where
> normally it would put it at the third insn.  Maybe we could treat
> compares specially?

We'd also need to do a SELECT_CC_MODE if we're replacing the operands of the comparison
and update the users of the CC reg from that comparison I believe.

>
> Do such cases happen a lot, btw?

I hacked together an extension to the cmpelim pass that merges such comparisons
(that previous passes like combine don't catch) and on aarch64 for SPEC2006 it merged
about 480 compares. If combine were extended as you described above I think it could catch
it, but it's a more complex and fragile pass than I feel comfortable hacking for this :)

Thanks,
Kyrill
>
> Segher



More information about the Gcc mailing list