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

[Quentin Colombet via llvm-dev]

Hi Daniel,

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.

The bottom line is I believe there are too many unknown to go down
that road just yet, but I am not the one doing the work, so your call
:D.

Just my 2c :P.

Cheers,
-Quentin

Le ven. 9 nov. 2018 à 08:36, David Greene via llvm-dev
<llvm-dev at lists.llvm.org> a écrit :
>
> Daniel Sanders via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
> > I've been working on the GlobalISel combiner recently and I'd like to
> > share the plan for how Combine Rules will be defined in GlobalISel and
> > solicit feedback on it.
>
> This is really great stuff!  I agree with pretty much everything Nicolai
> said, particularly the use of DAGs.  That's seems much more natually
> TableGen-y to me.  Specific comments are below.
>
> But before that, I've been long pained that we have so much duplicated
> code in instcombine and dagcombine.  I know this is way beyond the scope
> of this work but do you think the basic concepts could be applied to
> produce TableGen-generated instcombine passes?  It would be nice to
> re-use many of the rules, for example, except they'd match LLVM IR
> rather than MIR.  As you go about implementation, maybe keep this idea
> in mind?
>
> > Here's a simple example that eliminates a redundant G_TRUNC.
> >
> > def : GICombineRule<(defs root:$D, operand:$S),
> > (match [{MIR %1(s32) = G_ZEXT %S(s8)
> > %D(s16) = G_TRUNC %1(s32) }]),
> > (apply [{MIR %D(s16) = G_ZEXT %S(s8) }])>;
>
> The use of '%' vs. '$' here really threw me for a loop.  I would have
> expected '$D' and '$S' everywhere.  What's the significance of '%'
> vs. '$'?  I know MIR uses '%' for names but must that be the case in
> these match blocks?
>
> Of course if we go with Nicolai's use of DAGs this issue seems to go
> away.
>
> > * defs declares the interface for the rule. The definitions in the
> >   defs section are the glue between the Combine algorithm and the
> >   rule, as well as between the match and apply sections. In this case
> >   we only define the root of the match and that we have a register
> >   variable called $S.
>
> My understanding is that "root" means the sink here, but later in the
> "upside-down" example, "root" means the source.  It seems to me the use
> of "root" here is a misnomer/confusing.  I liked Nicolai's ideas about
> specifying the insert point.  Why do users need to know about "root" at
> all?  Is there some other special meaning attached to it?
>
>                                -David
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev