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

[Quentin Colombet via llvm-dev]

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.

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