This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Right way to represent flag-setting arithmetic instructions in MD files
On Mon, Mar 13, 2017 at 09:53:11AM +0000, Kyrill Tkachov wrote:
> >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.
Updating DF info can be slow. I'm not sure how bad it really would be
for combine. But, we do not even need to do a "full" update inside
combine.
Looking at all producer-consumer pairs is just as linear as only
looking at the first consumer for every producer. It is more work
of course, and it does not generally help all that much.
combine has quite a few problems caused by not working with DF (both
correctness bugs and missed optimisations).
> >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.
Yeah probably.
> >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 :)
Some people call it brave, some people call it foolish.
Segher