<div><div dir="auto">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?</div></div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 5, 2018 at 5:26 PM Kartik Cating-Subramanian via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">~Craig</div>