[llvm-dev] [RFC] Tablegen-erated GlobalISel Combine Rules

[Quentin Colombet via llvm-dev]

Hi Daniel,

I finally read the proposal.

I have a couple of comments that re-enforce what I was thinking
initially: it is too early IMHO to develop a full tablegen backend for
this. I believe we still miss ways to represent things that matters
(see my comments below) and I am afraid we still don't know all that
needs to be represented.

> It can reach across basic blocks when it's safe to do so. We may need to introduce a means to limit the inter-basic-block reach as I can foresee situations where it may pull expensive operations into a loop if it's not careful about this

I think we would need a syntax for that and in particular, I don't
think a generic heuristic based on frequency can solely solve the
problem (i.e., what you're hinting in your RFC).

Another thing that we miss has to do with the number of users. E.g.,
should a pattern only be applied if there is only one user? Is it
valid if there are more that one users, if we cannot move something
into the destination block can we still apply the pattern is we move
the result in the source block, etc.

The number of users may not be that relevant, but this gives use is a
notion of profitability (it is just how SDISel does this). This
actually ties back to the inter-basic-block case: is this pattern
profitable if it is between basic blocks with different frequencies.
In other words, I believe we should start to think in terms of how
profitable is a pattern. E.g., the source pattern as some cost and the
destination patterns as some other cost. Applying the pattern should
give us a profitability score, which would be higher when it produces
dead code (i.e., what the oneUse check tries to identify in SDISel).

Following that logic, we may get away with all the disabling specific
patterns kind of thing. I.e., if something is not profitable it does
not get applied.

All in all, the syntax that your suggesting is reasonable (though IMHO
MIR is going to limit our ability to share more logic with IR, but
maybe that's fine to give up on that goal?), but I feel it actually
distracts us from thinking about the problems we are solving and thus,
I am hesitant to stamp a work that would write a new tablegen backend.

That said, again, I am not the one doing the work!

Cheers,
-Quentin
[snip]