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

[Craig Topper via llvm-dev]

I’m not sure why you want to disable *all* load and stores. I could see
wanting to disable load folding into arithmetic operations, but disabling
the basic load and store to/from register will just cause isel to fail. Can
you elaborate more on your goal?

On Fri, Oct 5, 2018 at 5:26 PM Kartik Cating-Subramanian via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-- 
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181005/e7cbd666/attachment.html>