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

[Quentin Colombet via llvm-dev]

Hi David,

Le jeu. 29 nov. 2018 à 07:04, David Greene <dag at cray.com> a écrit :

> Quentin Colombet <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.

Cheers,
Q

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