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

On 10 May 2018 at 21:58, Andrew Trick <atrick at apple.com>
wrote:
> Fantastic writeup! It’s great to see so much progress on fundamental
> infrastructure.
>
> My time for LLVM code review is extremely limited. Can someone work with
> Andrea to get these patches in?
Hi Andrew,

Same here, but this has been a long goal for me, too, so I'll do my best.


-- 
cheers,
--renato

Thanks Andrew and Renato,

One think I didn't mention, and I should probably made it more explicit in
my RFC is that: "the new predicate framework is extensible".

That means, developers can extend it by adding new Check predicates.
As long as they also teach the PredicateExpander how to do the lowering for
those new predicates, then everything should be fine.

--

In the RFC I mentioned how we can use a TIIPredicate to let tablegen
auto-generate two version of function `isGPRZero`:
 1) a version that takes a MachineInstr as input, and that is automatically
generated by tablegen into the target-specific instruction info class.
  2) another version (still auto-generated by tablegen) that takes a MCInst
as input.

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

We can then introduce a new MCPredicate as follows:

```
// MCInstVariant and MachineInstVariant are both function names.
//
// MCinstVariant is the function to call if we want to check properties on
MCInst.
// MachineInstrVariant is the function to call if we want to check
properties on MachineInstr.

CheckFunction<string MCInstVariant, string MachineInstrVariant> :
MCPredicate {
  string MCinstFn = MCInstVariant;
  string MachineInstrFn = MachineInstrVariant;
}
```

Then we teach the PredicateExpander (in
utils/Tablegen/PredicateExpander.cpp|.h) how to lower that new predicate.

Here is an example of how this could be done:
```
void PredicateExpander::expandCheckFunction(formatted_raw_ostream &OS,
StringRef MCInstVariant, StringRef MachineInstrVariant) {
  if (shouldExpandForMC())
    OS << MCInstVariant;
  else
    OS << MachineInstrVariant;
  OS << "(MI)";
}
```

Basically, if we are generating code for MC, then we expand a call to "
MCInstVariant ". Otherwise, we expand a call to "
MachineInstrVariant"
(both user defined functions).

--

The bottom line is: the framework is extensible.
As long as we tell the PredicateExpander how to lower/expand our new
predicates, then we can implement different approaches.

I hope this answers to the comments from https://reviews.llvm.org/D46701.

Thanks,
Andrea

On Thu, May 10, 2018 at 10:24 PM, Renato Golin <renato.golin at
linaro.org>
wrote:
> On 10 May 2018 at 21:58, Andrew Trick <atrick at apple.com> wrote:
> > Fantastic writeup! It’s great to see so much progress on fundamental
> > infrastructure.
> >
> > My time for LLVM code review is extremely limited. Can someone work
with
> > Andrea to get these patches in?
>
> Hi Andrew,
>
> Same here, but this has been a long goal for me, too, so I'll do my
best.
>
>
> --
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180511/36e33c82/attachment.html>

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180511/f267ad35/attachment.html>