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

Sat Oct 6 12:31:18 PDT 2018

All of the only load and only store instruction also have mayLoad and
mayStore set. So that doesn't seem like an effective way to disable just
the "do-something-but-also-load-and-store".

I think you can stop most load folding by
making X86DAGToDAGISel::IsProfitableToFold return false. I don't have a
good answer for stores at the moment. But there are a lot fewer of those.

The Peephole pass will try to fold loads after isel and the register
allocator can fold stack spills and reloads. So you'll need to disable the
foldMemoryOperand* functions in X86InstrInfo.cpp.

~Craig

On Sat, Oct 6, 2018 at 10:44 AM Kartik Cating-Subramanian <kncs at cs.unc.edu>
wrote:

> Didn't mean *all* of them :).  It is pretty much what you are imagining.
> I am attempting to disable all the "do-something-but-also-load-and-store"
> instructions and I don't full understand dag patterns and the selection dag
> code yet.  I can add an extra field to X86Instr that is something akin to
> "AllowMemoryAccess". That way, I can selectively turn on and off specific
> instruction classes or multiclasses but it seemed tedious to manually tag
> every single instruction that read or wrote to memory.
>
> I primarily care only for the move, arithmetic, extension, control, and
> conditional instructions and not the ones that are for packed fused vector
> shuffles that cook you pizza. Maybe there's a more sensible way for me to
> correctly attach a predicate to all those instructions?  Or somehow write a
> predicate that would let me reference mayLoad or mayStore at from the C++
> code (I couldn't figure out how to get to the instruction given just a
> SubTarget object)?
>
> Thanks!
>
> Kartik
> On Fri, Oct 5, 2018 at 10:00 PM Craig Topper <craig.topper at gmail.com>
> wrote:
> >
> > 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/20181006/ffb41c86/attachment.html>