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

[Daniel Sanders via llvm-dev]

> On Nov 29, 2018, at 07:31, Quentin Colombet <quentin.colombet at gmail.com> wrote:
> 
> Hi David,
> 
> Le jeu. 29 nov. 2018 à 07:04, David Greene <dag at cray.com <mailto:dag at cray.com>> a écrit :
> Quentin Colombet <quentin.colombet at gmail.com <mailto:quentin.colombet at gmail.com>> writes:
> 
> >> I don't think I'd want to see things go that way.  Current SDISel
> >> patterns are very limited and impose a lot of hacky workarounds for
> >> not-too-uncommon things.  If anything, I anticipate migrating isel to
> >> what Daniel outlines rather than migrating combine to SDISel and then
> >> migrating to yet another thing after that.
> >
> > Interesting, I wasn't seeing this that way (the porting combine to SDISel bit).
> 
> Ok.  I though that's what you meant by, "use the syntax we already have
> for SDISel."  What do you have in mind?
> 
> That’s what I meant but for me it was not porting. I guess you’re thinking porting because of all your SDISel C++ code that you would be writing again in tablegen. I was thinking we were developing new code, not porting the C++ code, which is a mistake I realize now.
> 
> > The advantage I was seeing in reusing what we have is that ISel and
> > combines are fundamentally the same problem 
> 
> Yes!
> 
> > and any improvement (in particular compile time) that we would have
> > made to the existing matching state machine would have benefited
> > everything.
> 
> Whatever underlying algorithm is used, the TableGen syntax for the
> current SDISel could be improved.  It's never handled multiple outputs
> well, subregisters cause pain and so on.
> 
> Agree.
> 
> 
> 
> I'm agnostic on the underlying algorithm.
> 
> The algorithm is my concern to be honest :). The syntax as long as it is easy enough and expressive enough, I don’t really care. Though I keep thinking MIR is not the right abstraction.
> 
> 
> 
> > One thing I assumed from this proposal is that the new syntax would
> > imply a new matching state machine and thus fragmented our effort.
> 
> I think Daniel's intent is indeed to craft a new algorithm, but he
> should confirm that.  I don't know enough about the current algorithm to
> form an opinion on whether a new algorithm is justified.  I suspect the
> current algorithm reflects constraints in the current TableGen syntax,
> where it is hard to do certain realtively common things, but I don't
> know that for sure.
> 
> Agree and that’s where I believe we will start to fragment our effort.

I do have plans for a new combine algorithm but I'm still expecting to share the underlying matching state machine generator/optimizer/runner between Combine and ISel. The algorithm work I'm looking into is more about how it decides what matching rules to apply and when to apply them rather than how the pattern matching happens. I'll go into more detail on that in a separate thread once I've tested the idea on real code. Even if that ultimately fails and we stick with the current core algorithm, there's still some useful features that are enabled by having the tablegen definitions such as ruleset bisection, rule coverage, testing individual rules, opting out of certain target independent combines, less matching boilerplate, etc.

> Cheers,
> Q
> 
> 
>                                -David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181129/581fb7cf/attachment.html>