[llvm-dev] guessInstructionProperties, X86, mayLoad/Store and Predicates

[Kartik Cating-Subramanian via llvm-dev]

Hello!

As part of our project, we are trying to configure the LLVM X86
back-end to not select or schedule certain classes of instructions.  I
believe I can easily do that for some categories by using the platform
feature predicates in X86.td .  But I would like to disable larger
classes of instructions - say instructions that read from memory or
instructions that write to memory or have side-effects.  My initial
approach was an attempt to modify X86InstrFormat and, perhaps
appending a feature predicate to the Predicates field contingent on
mayLoad or mayStore being set.

class X86Inst<...> {
...
let Predicates = !if(!or(mayLoad,!mayStore), [UseLoadStores], []);
}

Now I get the clash between predicates and Requires and how the Mips
folks solved that and I can work around that issue just fine.
Unfortunately, I can't seem to access the mayLoad or mayStore bits in
time to use them in the predicate.  They come back as ? which causes
tablegen to error out when evaluating the !if expression.

Those bits seem to be generated in tablegen with a fall-back path (for
guessInstructionProperties = 1) where it simply clears both mayLoad
and mayStore and sets hasSideEffects.  Turning off
guessInstructionProperties for X86 seems to result in tens of
thousands of failures where patters can't infer these effects - most
of which seem to indeed depend on the behavior that mayStore = 0 and
mayLoad = 0 by default unless it can be inferred otherwise.

Do you know of any way I could actually acquire the inferred
mayLoad/mayStore properties for an instruction from within the
tablegen language?  Alternatively, does it make sense to hack into
tablegen at CodeGenDAGPatterns::CodeGenDAGPatterns and have a step
after InferInstructionFlags() that then rewrites the predicate list of
all patterns based on the instructions I wish to include/exclude?  I
cannot quite figure out how the various tablegen backends maintain the
relationship between the parsed instruction record and the many
different patterns it generates from it.  Would simply iterating over
PatternsToMatch in CodeGenDAGPatterns and appending an extra Predicate
work well enough for all the back-ends?  Any smarter way to pull this
all off?

Of course I also understand there's the "painful" way to do this,
which is to actually go into all the X86Instr*.td files and manually
write mayLoad and mayStore entries for the instructions I care about
so those values are indeed available to be referenced in the X86Inst
record.  Is there any plan to actually move X86 .td files towards such
explicit annotation such as RISC-V with it actually setting mayLoad
and mayStore explicitly?  Would even partially doing that be valuable
to y'all?

Thank you!

Kartik