<div dir="auto">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.<br>
<br>
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)?<br>
<br>Thanks!<div dir="auto"><br>
Kartik<br>
On Fri, Oct 5, 2018 at 10:00 PM Craig Topper <<a href="mailto:craig.topper@gmail.com" target="_blank" rel="noreferrer">craig.topper@gmail.com</a>> wrote:<br>
><br>
> 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?<br>
><br>
> On Fri, Oct 5, 2018 at 5:26 PM Kartik Cating-Subramanian via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> Hello!<br>
>><br>
>> As part of our project, we are trying to configure the LLVM X86<br>
>> back-end to not select or schedule certain classes of instructions.  I<br>
>> believe I can easily do that for some categories by using the platform<br>
>> feature predicates in X86.td .  But I would like to disable larger<br>
>> classes of instructions - say instructions that read from memory or<br>
>> instructions that write to memory or have side-effects.  My initial<br>
>> approach was an attempt to modify X86InstrFormat and, perhaps<br>
>> appending a feature predicate to the Predicates field contingent on<br>
>> mayLoad or mayStore being set.<br>
>><br>
>> class X86Inst<...> {<br>
>> ...<br>
>> let Predicates = !if(!or(mayLoad,!mayStore), [UseLoadStores], []);<br>
>> }<br>
>><br>
>> Now I get the clash between predicates and Requires and how the Mips<br>
>> folks solved that and I can work around that issue just fine.<br>
>> Unfortunately, I can't seem to access the mayLoad or mayStore bits in<br>
>> time to use them in the predicate.  They come back as ? which causes<br>
>> tablegen to error out when evaluating the !if expression.<br>
>><br>
>> Those bits seem to be generated in tablegen with a fall-back path (for<br>
>> guessInstructionProperties = 1) where it simply clears both mayLoad<br>
>> and mayStore and sets hasSideEffects.  Turning off<br>
>> guessInstructionProperties for X86 seems to result in tens of<br>
>> thousands of failures where patters can't infer these effects - most<br>
>> of which seem to indeed depend on the behavior that mayStore = 0 and<br>
>> mayLoad = 0 by default unless it can be inferred otherwise.<br>
>><br>
>> Do you know of any way I could actually acquire the inferred<br>
>> mayLoad/mayStore properties for an instruction from within the<br>
>> tablegen language?  Alternatively, does it make sense to hack into<br>
>> tablegen at CodeGenDAGPatterns::CodeGenDAGPatterns and have a step<br>
>> after InferInstructionFlags() that then rewrites the predicate list of<br>
>> all patterns based on the instructions I wish to include/exclude?  I<br>
>> cannot quite figure out how the various tablegen backends maintain the<br>
>> relationship between the parsed instruction record and the many<br>
>> different patterns it generates from it.  Would simply iterating over<br>
>> PatternsToMatch in CodeGenDAGPatterns and appending an extra Predicate<br>
>> work well enough for all the back-ends?  Any smarter way to pull this<br>
>> all off?<br>
>><br>
>> Of course I also understand there's the "painful" way to do this,<br>
>> which is to actually go into all the X86Instr*.td files and manually<br>
>> write mayLoad and mayStore entries for the instructions I care about<br>
>> so those values are indeed available to be referenced in the X86Inst<br>
>> record.  Is there any plan to actually move X86 .td files towards such<br>
>> explicit annotation such as RISC-V with it actually setting mayLoad<br>
>> and mayStore explicitly?  Would even partially doing that be valuable<br>
>> to y'all?<br>
>><br>
>> Thank you!<br>
>><br>
>> Kartik<br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
> --<br>
> ~Craig<br></div></div>