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

[Daniel Sanders via llvm-dev]

> On Nov 28, 2018, at 14:56, Quentin Colombet <quentin.colombet at gmail.com> wrote:
> 
> Le mer. 28 nov. 2018 à 11:41, David Greene <dag at cray.com <mailto:dag at cray.com>> a écrit :
>> 
>> Quentin Colombet <quentin.colombet at gmail.com> writes:
>> 
>>>    And are there any realistic alternatives for declarative
>>>    representations combines?
>>> 
>>> Realistic I would have thought we can use the syntax we already have
>>> for SDISel.
>>> In other words, people wouldn’t have to learn yet another way of doing
>>> combines and when we are ready we can move everything (isel +
>>> combines) in one go.
>> 
>> 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).
> 
> The advantage I was seeing in reusing what we have is that ISel and
> combines are fundamentally the same problem and any improvement (in
> particular compile time) that we would have made to the existing
> matching state machine would have benefited everything. One thing I
> assumed from this proposal is that the new syntax would imply a new
> matching state machine and thus fragmented our effort.

It's definitely going to require some changes to that state machine but the intent is to have both use the same core.

> Again maybe that's a good thing (get rid of the past to better prepare
> the future), and maybe I misread the proposal and we actually reuse
> the same state machine and we are just discussing syntactic sugar.
> Point being, feel free to move as you see fit and take my comments as
> they are, a single person's opinion :).
> 
> Cheers,
> Q.
> 
>> 
>>                        -David

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