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

[Kartik Cating-Subramanian via llvm-dev]

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/967669c3/attachment.html>