The goal of this RFC is to make information related to variant scheduling
classes accessible at MC level. This would help tools like llvm-mca
understand/resolve variant scheduling classes.
To achieve this goal, I plan to introduce a new class of scheduling predicates
named MCSchedPredicate. An MCSchedPredicate allows the definition of boolean
expressions with a well-known semantic, that can be used to generate code for
both MachineInstr and MCInst.
The new predicates are designed to be completely optional. Scheduling models
can use a combination of SchedPredicate and MCSchedPredicate to describe
variant reads and writes. Old scheduling predicate definitions would still be
valid. New MCSchedPredicates would behave like normal scheduling predicates.
A bit of background
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?
Same here, but this has been a long goal for me, too, so I'll do my best.
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.
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.
The auto generated target hook is not a virtual method. It is always a
static member of the XXXGenInstrInfo class automatically generated by
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
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`.