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

[Nicolai Hähnle via llvm-dev]

On 28.11.18 23:56, Quentin Colombet via llvm-dev wrote:
> Le mer. 28 nov. 2018 à 11:41, David Greene <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.

Right, they are fundamentally the same thing, but as David said the 
current SDISel syntax is quite limiting. Multi-root patterns, 
instructions with multiple outputs, advanced special matches are all 
fairly awkward to express if they're possible at all.

I think Daniel's proposal fixes all these deficiencies, and I like the 
new variant that uses the TableGen dag type for S-expressions a lot. 
It's really not that different from SDISel in the end.

Cheers,
Nicolai


> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.