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

[David Greene via llvm-dev]

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?

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

I'm agnostic on the underlying algorithm.

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

                               -David