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

[Nicolai Hähnle via llvm-dev]

On 09.11.18 18:47, Quentin Colombet wrote:
> Le ven. 9 nov. 2018 à 09:24, Nicolai Hähnle <nhaehnle at gmail.com> a écrit :
>>
>> Hi Quentin,
>>
>> On 09.11.18 18:16, Quentin Colombet via llvm-dev wrote:
>>> Disclaimer: Haven't read the proposal yet.
>>>
>>>>    TL;DR: We're planning to define GlobalISel Combine Rules using MIR syntax with a few bits glued on to interface with the algorithm and escape into C++ when we need to. Eventually, ISel rules may follow suit.
>>>
>>> I would rather avoid adding a dependency on yet another tablegen
>>> backend to the project unless we are confident it is here to stay.
>>> At a high level, I am not fan of the proposal because it will box us
>>> in a stricter framework that pure C++ that may impede our ability to
>>> prototype different approaches quickly. Longer term, I would like to
>>> have a common framework to IR and MIR to describe combines and I am
>>> afraid that MIR is not the right abstraction for that.
>>
>> What do you mean by "prototype different approaches quickly"?
> 
> I mean exploring different combine strategies :).
> With a model we are stuck with what it was designed to express.
> For instance, currently with SDISel there are no way to express
> something like paired loads, i.e., patterns like this:
> load @a, load @a + 4 => loadpair @a
> 
> Because the DAGs needs to be single rooted.
> In C++ we do whatever we want (I am not saying it is easy ;).)

Of course that particular example may not be the best since Daniel is 
already talking about multi-root rules ;)


>> It's funny, because I always thought the exact opposite: I felt like
>> there are constraints in the freedom to explore different approaches
>> precisely because the combines are not described declaratively, and too
>> much of how everything fits together is de facto hardcoded in C++.
>>
>> But maybe we mean different things?
> 
> I think we meant the same think and I admit I don't see how C++ could
> be more constrained than a declarative description that rely on C++
> code to be executed :).
> I agree that declarative syntax is easier to express and rewrite though.

C++ is less restrictive, but that's precisely why it makes it harder to 
do certain experiments :)

I was thinking of experiments along the lines of semi-automatically 
combining rewrite rules for something similar to super-optimization. 
With a declarative description of rewrite rules, you might be able to 
combine them algorithmically to go beyond simple local improvements.

I admit that's a bit speculative, but the point is that if all the rules 
are hidden in C++, there's not even a place to start from.

I'll grant you that there are other kinds of experiments that are easier 
in C++. The proposal does suggest escape hatches for that...

Cheers,
Nicolai

> 
>>
>> I do agree with you that MIR code blocks seem like the wrong model for
>> describing combines.
>>
>> Cheers,
>> Nicolai
>>

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