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
