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

[Quentin Colombet via llvm-dev]

Hi Nicolai,

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

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

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