<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Starting off with the question: Should Pattern objects (standalone match rules that are not part of an Instruction definition) inherit the Predicates of the Instruction(s?) referenced in ResultInstrs? Is there a counter-example where a
target would want to match and select an instruction, even though the instruction is illegal in the given configuration?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I found a somewhat relevant email from back in 2019, “Please expose predicates to MachineVerifier” that has the quote: “…currently, at least for some targets, we use Requires predicates on instructions which are legal, but we don’t want
the TableGen’ed isel to select for some reason.” This seems like the inverse of my question, and logically makes sense. However, selecting an instruction which isn’t legal does not make logical sense to me.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">My experience which prompted the question follows<o:p></o:p></p>
<p class="MsoNormal">-----<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Our downstream target automatically generates Instruction definitions as a sort of ISA database for our LLVM target. We then utilize this database when defining the instruction selection automaton’s rules.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In database (automatically generated):<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">def AddInstr : Instruction<…> {<o:p></o:p></p>
<p class="MsoNormal"> // Encoding, operands, implicit defs/uses, etc.<o:p></o:p></p>
<p class="MsoNormal"> …<o:p></o:p></p>
<p class="MsoNormal"> // No ISel code<o:p></o:p></p>
<p class="MsoNormal"> let Pattern = [];<o:p></o:p></p>
<p class="MsoNormal">}<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In backend definitions (manually written):<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">// Match LLVM IR add of i32s into AddInstr<o:p></o:p></p>
<p class="MsoNormal">def : Pat<(add i32:$src1, i32:$src2), (AddInstr i32:$src1, i32:$src2)>;<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Now consider the introduction of a subtarget that doesn’t include AddInstr as part of the ISA. It was fairly easy to generate the following:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">def AddInstr : Instruction<…>, Requires<[IsNotSubtarget]> {<o:p></o:p></p>
<p class="MsoNormal" style="text-indent:.5in">…<o:p></o:p></p>
<p class="MsoNormal">}<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This resulted in useful code from the assembly parser, disassembler, and MCCodeEmitter for verification. However, it did not affect the instruction selector in any way. ISel still matched the above Pattern without diagnostics, and an inspection
of the tablegen’d selection DAG did not contain any commands to check a predicate. What confuses me is that there is a ‘Predicates’ field for both Pattern objects as well as for the instruction that patterns reference, but they do not interact at all.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In the TableGen backend CodeGenDAGPatterns, I see that the backend finds instructions in the destination pattern:<o:p></o:p></p>
<p class="MsoNormal"><a href="https://github.com/llvm/llvm-project/blob/44ce487bfe8badc3e3718e7cc81c289540e6725d/llvm/utils/TableGen/CodeGenDAGPatterns.cpp#L3993">https://github.com/llvm/llvm-project/blob/44ce487bfe8badc3e3718e7cc81c289540e6725d/llvm/utils/TableGen/CodeGenDAGPatterns.cpp#L3993</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So couldn’t this model be used to append referenced Instruction Predicates onto the Pattern object? This avoids duplication and, at least in our case, allows the responsibility of getting Predicates right to be placed on the automatic generation,
rather than a human developer.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">J.B Nagurne<o:p></o:p></p>
<p class="MsoNormal">Code Generation<o:p></o:p></p>
<p class="MsoNormal">Texas Instruments<o:p></o:p></p>
</div>
</body>
</html>