[llvm-dev] [RFC] MC support for variant scheduling classes.

Andrea Di Biagio via llvm-dev llvm-dev at lists.llvm.org
Fri May 11 12:33:17 PDT 2018


On Fri, May 11, 2018 at 6:00 PM, Andrew Trick <atrick at apple.com> wrote:

>
>
> On May 11, 2018, at 4:26 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com>
> wrote:
>
> The goal is to help users defining a predicate the check logic. If we use
> a TIIPredicate, we specify the logic only once, in a declarative way, and
> then we let tablegen generate code for us.
>
> If for some reason, a user doesn't want to use this approach, then they
> can still provide their own implementation for variant 2. (i.e. the version
> of `isGPRZero` that takes a MCInst as input).
>
>
> The important thing is that users can call into target-specific TII entry
> points (i.e. not declared in TargetInstrInfo as a virtual method). The
> reason I provided a C++ hook is so that users could do this without
> learning the tablegen backend. Although if it’s easy to define a new target
> specific TIIPredicate, that’s fine too.
>
> -Andy
>

I agree.
The auto generated target hook is not a virtual method. It is always a
static member of the XXXGenInstrInfo class automatically generated by
tablegen.

The latest version of patch 1 (https://reviews.llvm.org/D46695) also added
a new `CheckFunctionCall` predicate.
People that don't find easy to use a TIIPredicate can now use a
CheckFunctionCall instead. Overall, I think it is good to have alternatives
to using TIIPredicate; some TII hooks used for predicates can be very long,
and converting them into predicates can be error prone. Spotting logical
mistakes in auto-generated (especially in big code blocks) can be difficult
and annoying.
Ideally, TIIPredicate will be used in most cases where the predicate
function is small. If the logic gets too complicated, then people can
always use a `CheckFunctionCall`.

Cheers
-Andrea
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180511/0cae1721/attachment.html>


More information about the llvm-dev mailing list