<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=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:"Ericsson Hilda";
panose-1:0 0 5 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
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;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New",serif;}
tt
{mso-style-priority:99;
font-family:"Courier New",serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.xapple-converted-space
{mso-style-name:xapple-converted-space;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Ericsson Hilda",serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
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=SV link=blue vlink=purple><div class=WordSection1><p class=MsoNormal style='margin-left:65.2pt'><span style='font-family:"Ericsson Hilda",serif;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span style='font-family:"Ericsson Hilda",serif;mso-fareast-language:EN-US'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='margin-left:65.2pt'><b><span lang=EN-US>From:</span></b><span lang=EN-US> Daniel Sanders <daniel_l_sanders@apple.com> <br><b>Sent:</b> den 9 juni 2020 20:21<br><b>To:</b> Gabriel Hjort Åkerlund <gabriel.hjort.akerlund@ericsson.com><br><b>Cc:</b> Quentin Colombet <qcolombet@apple.com>; Dominik Montada <dominik.montada@hightec-rt.com>; llvm-dev@lists.llvm.org<br><b>Subject:</b> Re: [llvm-dev] Nested instruction patterns rejected by GlobalISel when having registers in Defs<o:p></o:p></span></p></div></div><p class=MsoNormal style='margin-left:65.2pt'><o:p> </o:p></p><p class=MsoNormal style='margin-left:65.2pt'><o:p> </o:p></p><div><p class=MsoNormal style='margin-left:65.2pt'><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal style='margin-left:65.2pt'>On 8 Jun 2020, at 08:13, Gabriel Hjort Åkerlund <<a href="mailto:gabriel.hjort.akerlund@ericsson.com">gabriel.hjort.akerlund@ericsson.com</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal style='margin-left:65.2pt'><o:p> </o:p></p><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt'>Hi Daniel,</span><o:p></o:p></p></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt'> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt'>Thanks for replying; I was hoping to get in touch with you on this issue.</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt'> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt'>I had a look at how SelectionIDAG does it when generating the matcher table, and it does consider the implicit defs as additional output. Here is the match table generated for the pattern:</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt'> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 0*/ OPC_CheckOpcode, TARGET_VAL(ISD::SIGN_EXTEND),</span><o:p></o:p></p></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 3*/ OPC_MoveChild0,</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 4*/ OPC_CheckOpcode, TARGET_VAL(ISD::SHL),</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 7*/ OPC_MoveChild0,</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 8*/ OPC_CheckOpcode, TARGET_VAL(ISD::ANY_EXTEND),</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 11*/ OPC_RecordChild0, // #0 = $src</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 12*/ OPC_CheckChild0Type, MVT::i16,</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 14*/ OPC_MoveParent,</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 15*/ OPC_RecordChild1, // #1 = $imm</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 16*/ OPC_MoveChild1,</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 17*/ OPC_CheckOpcode, TARGET_VAL(ISD::Constant),</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 20*/ OPC_CheckPredicate, 0, // Predicate_Imm_17_31_i16</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 22*/ OPC_CheckType, MVT::i16,</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 24*/ OPC_MoveParent,</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 25*/ OPC_CheckType, MVT::i32,</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 27*/ OPC_MoveParent,</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 28*/ OPC_CheckType, MVT::i40,</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 30*/ OPC_EmitNode1, TARGET_VAL(TargetOpcode::IMPLICIT_DEF), 0,</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> MVT::i40, 0/*#Ops*/, // Results = #2</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 36*/ OPC_EmitNode1, TARGET_VAL(TargetOpcode::IMPLICIT_DEF), 0,</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> MVT::i32, 0/*#Ops*/, // Results = #3</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 42*/ OPC_EmitInteger, MVT::i32, OurTarget::hi16, // Results = #4</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 45*/ OPC_EmitNode1, TARGET_VAL(TargetOpcode::INSERT_SUBREG), 0,</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> MVT::i32, 3/*#Ops*/, 3, 0, 4, // Results = #5</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 54*/ OPC_EmitNode1, TARGET_VAL(OurTarget::clearLo32_pseudo), 0,</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> MVT::i32, 1/*#Ops*/, 5, // Results = #6</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 61*/ OPC_EmitInteger, MVT::i16, 0,<span class=apple-converted-space> </span></span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 64*/ OPC_EmitRegister, MVT::i16, 0 /*zero_reg*/,</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 67*/ OPC_EmitInteger, MVT::i16, 0,<span class=apple-converted-space> </span></span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><b><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 70*/ OPC_EmitNode2, TARGET_VAL(OurTarget::shfts_a32_imm7), 0,</span></b><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><b><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> MVT::i32, MVT::i16, 5/*#Ops*/, 6, 1, 7, 8, 9, // Results = #10 #11</span></b><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 82*/ OPC_EmitInteger, MVT::i32, OurTarget::acc,</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 85*/ OPC_EmitNode1, TARGET_VAL(TargetOpcode::INSERT_SUBREG), 0,</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> MVT::i40, 3/*#Ops*/, 2, 10, 12, // Results = #13</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 94*/ OPC_EmitInteger, MVT::i16, 0,<span class=apple-converted-space> </span></span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span style='font-size:12.0pt;font-family:"Courier New",serif'>/* 97*/ OPC_EmitRegister, MVT::i16, 0 /*zero_reg*/,</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span style='font-size:12.0pt;font-family:"Courier New",serif'>/* 100*/ OPC_EmitInteger, MVT::i16, 0,<span class=apple-converted-space> </span></span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 103*/ OPC_MorphNodeTo1, TARGET_VAL(OurTarget::sext_a32), 0,</span><o:p></o:p></p></div></div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> MVT::i40, 4/*#Ops*/, 13, 14, 15, 16, ...</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt'> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt'>The line of interest here is the one below<span class=apple-converted-space> </span></span><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/* 70 */</span><span lang=EN-US style='font-size:12.0pt'>. There, we can see that the instruction produces two results of type<span class=apple-converted-space> </span></span><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>MVT::i32</span><span class=apple-converted-space><span lang=EN-US style='font-size:12.0pt'> </span></span><span lang=EN-US style='font-size:12.0pt'>(the value produced by the instruction) respectively<span class=apple-converted-space> </span></span><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>MVT::i16</span><span class=apple-converted-space><span lang=EN-US style='font-size:12.0pt'> </span></span><span lang=EN-US style='font-size:12.0pt'>(the CCReg updated by the instruction). These are labeled as results<span class=apple-converted-space> </span></span><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>#10</span><span class=apple-converted-space><span lang=EN-US style='font-size:12.0pt'> </span></span><span lang=EN-US style='font-size:12.0pt'>respectively<span class=apple-converted-space> </span></span><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>#11</span><span lang=EN-US style='font-size:12.0pt'>. Looking at operand identifiers after<span class=apple-converted-space> </span></span><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>/*#Ops*/</span><span lang=EN-US style='font-size:12.0pt'>, we can see that only<span class=apple-converted-space> </span></span><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>#10</span><span class=apple-converted-space><span lang=EN-US style='font-size:12.0pt'> </span></span><span lang=EN-US style='font-size:12.0pt'>is used by the rest of the resulting pattern (by<span class=apple-converted-space> </span></span><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>INSERT_SUBREG</span><span lang=EN-US style='font-size:12.0pt'>), which is as intended.</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt'> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt'>However, in the destination pattern declared in the *.td file, there is no information pertaining to which of the results should be used by the parent node. Since only tree-shaped patterns are allowed, SelectionIDAG must somehow decide which of the results are to be used by the parent node. And this decision is taken at lines 869-870 in<span class=apple-converted-space> </span></span><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'>DAGISelMatcherGen.cpp</span><span lang=EN-US style='font-size:12.0pt'>:<span class=apple-converted-space> </span></span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt'> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> ...</span><o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> unsigned FinalNumOps = InstOps.size() + NumSubOps;</span><o:p></o:p></p></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> while (InstOps.size() < FinalNumOps) {</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> const TreePatternNode *Child = N->getChild(ChildNo);</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> unsigned BeforeAddingNumOps = InstOps.size();</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> EmitResultOperand(Child, InstOps);</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> assert(InstOps.size() > BeforeAddingNumOps && "Didn't add any operands");</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> // If the operand is an instruction and it produced multiple results, just</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> // take the first one.</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> if (!Child->isLeaf() && Child->getOperator()->isSubClassOf("Instruction"))</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> InstOps.resize(BeforeAddingNumOps+1);</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> ++ChildNo;</span><o:p></o:p></p></div></div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> }</span><o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif'> ...</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt'> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt'>In other words, if a child produces more than one result SelectionIDAG always takes the first result. Those two lines originate from a patch by Chris Lattner (r99725), so presumably this is the correct way of doing it. If GlobalISel were to do the same, it would solve the issue I'm having with our patterns.</span><o:p></o:p></p></div></div></div></blockquote><div><p class=MsoNormal style='margin-left:65.2pt'><o:p> </o:p></p></div><p class=MsoNormal style='margin-left:65.2pt'>Thanks for looking into that.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:65.2pt'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:65.2pt'>There's three questions I feel I have with the SelectionDAG behaviour:<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:65.2pt'>* If Defs=[A] causes SelectionDAG to add a result to the intermediate SDNode, why doesn't Defs=[A,B] add two?<o:p></o:p></p><p class=MsoNormal><span style='font-family:"Ericsson Hilda",serif'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>That’s because CodeGenDAGPatterns::GetNumNodeResults() does the following:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif;color:black'> if (Operator->isSubClassOf("Instruction")) {<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif;color:black'> CodeGenInstruction &InstInfo = CDP.getTargetInfo().getInstruction(Operator);<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif;color:black'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif;color:black'> unsigned NumDefsToAdd = InstInfo.Operands.NumDefs;<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif;color:black'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif;color:black'> // Subtract any defaulted outputs.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif;color:black'> for (unsigned i = 0; i != InstInfo.Operands.NumDefs; ++i) {<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif;color:black'> Record *OperandNode = InstInfo.Operands[i].Rec;<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif;color:black'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif;color:black'> if (OperandNode->isSubClassOf("OperandWithDefaultOps") &&<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif;color:black'> !CDP.getDefaultOperand(OperandNode).DefaultOps.empty())<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif;color:black'> --NumDefsToAdd;<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif;color:black'> }<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif;color:black'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif;color:black'> // Add on one implicit def if it has a resolvable type.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif;color:black'> if (InstInfo.HasOneImplicitDefWithKnownVT(CDP.getTargetInfo()) !=MVT::Other)<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif;color:black'> ++NumDefsToAdd;<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif;color:black'> return NumDefsToAdd;<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New",serif;color:black'> }<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>In other words, when building the patterns any additional </span><span lang=EN-US style='font-family:"Courier New",serif'>Defs</span><span lang=EN-US style='font-family:"Ericsson Hilda",serif'> are simply ignored, and I think this is due to how the functionality evolved. Here are the commits related to this issue:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'>commit f144725ebcd859009c6ee96ead4a2d09ab3d277c<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'>Author: Chris Lattner <sabre@nondot.org><o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'>Date: Fri Mar 19 21:37:09 2010 +0000<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> major surgery on tblgen: generalize TreePatternNode<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> to maintain a list of types (one for each result of<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> the node) instead of a single type. There are liberal<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> hacks added to emulate the old behavior in various<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> situations, but they can start disolving now.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> <o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> llvm-svn: 98999<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'>commit d44966f26de2e7ca05cb888a1ea5b5bdc22a65c0<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'>Author: Chris Lattner <sabre@nondot.org><o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'>Date: Sat Mar 27 19:15:02 2010 +0000<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> continue pushing tblgen's support for nodes with multiple<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> results forward. We can now handle an instruction that<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> produces one implicit def and one result instead of one or<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> the other when not at the root of the pattern.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> <o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> llvm-svn: 99725<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'>commit 7bc5d9b576827b4c629e7dd6707804ee61ef18c9<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'>Author: Chris Lattner <sabre@nondot.org><o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'>Date: Sat Mar 27 20:09:24 2010 +0000<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> hoist some funky logic into CodeGenInstruction<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> from two places in CodeGenDAGPatterns.cpp, and<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> use it in DAGISelMatcherGen.cpp instead of using<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> an incorrect predicate that happened to get lucky<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> on our current targets.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> <o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> llvm-svn: 99726<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'>commit 3a8eb896c9d6696402bf113653c4c20b237c7009<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'>Author: Craig Topper <craig.topper@gmail.com><o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'>Date: Fri Mar 20 05:09:06 2015 +0000<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> [Tablegen] Attempt to add support for patterns containing nodes with multiple results.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> <o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> This is needed for AVX512 masked scatter/gather support.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> <o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> The R600 change is necessary to remove a hack that was working around the lack of multiple results.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> <o:p></o:p></span></p><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-family:"Courier New",serif'> llvm-svn: 232798<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>My guess is that the support for multiple results simply stopped at one result from </span><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>outs</span><span lang=EN-US style='font-family:"Ericsson Hilda",serif'> and one from </span><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>Defs</span><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'><o:p> </o:p></span></p></div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US>* Given that SDNode's support MVT::Other results, why doesn't MVT::Other behave the same way?<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>Hm, cannot answer that; I don’t know what SDNode’s support for MVT::Other looks like.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'><o:p> </o:p></span></p></div><div><p class=MsoNormal style='margin-left:65.2pt'>* If nothing can use that result, why model it? I suppose custom C++ instruction selection can still see it so maybe that's it but if so, what code is relying on it?<o:p></o:p></p><p class=MsoNormal><span style='font-family:"Ericsson Hilda",serif'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>Perhaps the commit above from Crag Topper can answer that. I haven’t looked deeper into that, though.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'><o:p> </o:p></span></p></div><div><p class=MsoNormal style='margin-left:65.2pt'>The inconsistency makes me rather suspicious about it. It feels like it was a hack for a specific purpose but I don't know what that purpose is. Overall, I'm not keen to carry it forwards unless there's a clear reason it's there.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:65.2pt'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:65.2pt'>Leaving that aside for the moment. I see a difference in modelling that makes directly importing the SelectionDAG behaviour tricky. SelectionDAG uses SDNode's which keep the result list (+ the first implicit def with known type) and the operand list separate. GlobalISel uses the MachineInstr's which uses a single list in a fixed order. That order is outputs, inputs, implicits so we would need to split the results list into two pieces and defer adding the implicit def to the place it's currently added to handle it the SelectionDAG way. That being the case (and assuming we don't find a good reason for SelectionDAG's behaviour), I think the best approach for this might be to adjust the numbers that originate from GetNumNodeResults() for the `InstInfo.HasOneImplicitDefWithKnownVT(CDP.getTargetInfo()) !=MVT::Other` case to undo the adjustment CodeGenDAGPatterns does. That's an ugly solution but I think the other ones I can think of are worse.<o:p></o:p></p><p class=MsoNormal><span style='font-family:"Ericsson Hilda",serif'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>I am probably missing something here, but why does GlobalISel need to care about implicit defs at all? Since there seems to be no way of referring to such values in the patterns, why not just ignore them from instruction selection’s point of view? As far as I know, only the register allocator needs to know about which registers are implicitly used or defined by an instruction.<o:p></o:p></span></p></div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US><br><br><o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt'>Best regards,</span><o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt'>Gabriel</span><o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:12.0pt'> </span><o:p></o:p></p></div></div><div class=MsoNormal align=center style='margin-left:65.2pt;text-align:center'><hr size=2 width="98%" align=center></div><div id=divRplyFwdMsg><div><p class=MsoNormal style='margin-left:65.2pt'><b><span lang=EN-US>From:</span></b><span class=apple-converted-space><span lang=EN-US> </span></span><span lang=EN-US>Daniel Sanders <<a href="mailto:daniel_l_sanders@apple.com">daniel_l_sanders@apple.com</a>><br><b>Sent:</b><span class=apple-converted-space> </span>Friday, June 5, 2020 9:02 PM<br><b>To:</b><span class=apple-converted-space> </span>Quentin Colombet <<a href="mailto:qcolombet@apple.com">qcolombet@apple.com</a>><br><b>Cc:</b><span class=apple-converted-space> </span>Dominik Montada <<a href="mailto:dominik.montada@hightec-rt.com">dominik.montada@hightec-rt.com</a>>; Gabriel Hjort Åkerlund <<a href="mailto:gabriel.hjort.akerlund@ericsson.com">gabriel.hjort.akerlund@ericsson.com</a>>; <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br><b>Subject:</b><span class=apple-converted-space> </span>Re: [llvm-dev] Nested instruction patterns rejected by GlobalISel when having registers in Defs</span><o:p></o:p></p></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US> </span><o:p></o:p></p></div></div></div><div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US>The implicit defs don't participate much in the patterns. For the most part it's just read into CodeGenInstruction::ImplicitDefs and then GlobalISel gathers and adds them all at the end. I think I do see the code Gabriel is referring to though.</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US>GetNumNodeResults() has:</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US> if (InstInfo.HasOneImplicitDefWithKnownVT(CDP.getTargetInfo()) !=MVT::Other)</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US> ++NumDefsToAdd;</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US>and ultimately this VT gets into Types via UpdateNodeType(). I have no idea why this code does this as I don't really see why the VT matters to how you treat an implicit def. This code dates back to 2010 (r99726) and that commit called it 'funky logic' so it's unlikely that we'll find someone that remembers it.</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US>Does your CCReg need to have a specific type? If not, then you could make it MVT::Other and the problem should go away.</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US>Have you looked into how DAGISel supports these patterns? This code is common between DAGISel and GlobalISel so given that DAGISel works it must be doing something to handle this that's missing from GlobalISel.</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US><br><br><br></span><o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US>On 5 Jun 2020, at 11:02, Quentin Colombet <</span><a href="mailto:qcolombet@apple.com"><span lang=EN-US style='color:purple'>qcolombet@apple.com</span></a><span lang=EN-US>> wrote:</span><o:p></o:p></p></div></div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US> </span><o:p></o:p></p></div><div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US>+ Daniel who knows the most about the table gen importer</span><o:p></o:p></p></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US><br><br><br></span><o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US>On Jun 5, 2020, at 12:48 AM, Dominik Montada via llvm-dev <</span><a href="mailto:llvm-dev@lists.llvm.org"><span lang=EN-US style='color:purple'>llvm-dev@lists.llvm.org</span></a><span lang=EN-US>> wrote:</span><o:p></o:p></p></div></div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US> </span><o:p></o:p></p></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:9.0pt;font-family:"Helvetica",sans-serif'>Hi Gabriel,</span><o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:9.0pt;font-family:"Helvetica",sans-serif'>Your comment made me take a look at our instruction definitions and patterns in a little bit more detail. And while we do use nested patterns with INSERT_SUBREG, apparently none of those patterns use instructions with implicit-defs. Sorry for misleading you there by a wrong assumption on my part.</span><o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:9.0pt;font-family:"Helvetica",sans-serif'>However, I still find it strange that TableGen should reject such a pattern. I'm really not sure if this is simply an overlooked use-case or if there is some real reasoning behind this logic. If it were an actual output register I could understand it, but since this is an implicit one it should not impact the pattern in my opinion.</span><o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:9.0pt;font-family:"Helvetica",sans-serif'>Sorry for not being able to help out with the actual problem after all!</span><o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:65.2pt'><span style='font-size:9.0pt;font-family:"Helvetica",sans-serif'>Cheers,</span><o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:65.2pt'><span style='font-size:9.0pt;font-family:"Helvetica",sans-serif'>Dominik</span><o:p></o:p></p></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span style='font-size:9.0pt;font-family:"Helvetica",sans-serif'>Am 04.06.20 um 15:06 schrieb Gabriel Hjort Åkerlund:</span><o:p></o:p></p></div></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt;font-variant-caps: normal;text-align:start;word-spacing:0px'><div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US>Hi Dominik,</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US>Thanks for your reply.</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US>In my case, the<span class=xapple-converted-space> </span></span><span lang=EN-US style='font-family:"Courier New",serif'>Defs</span><span class=xapple-converted-space><span lang=EN-US style='font-family:"Ericsson Hilda",serif'> </span></span><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>is the cause of the problem. Or rather, it is part of the problem, because when I remove it from the instruction TableGen gives me a different error message which concerns a part which is deeper into the pattern tree, so at least it is able to proceed beyond that part of the pattern. I have also stepped TableGen inside<span class=xapple-converted-space> </span></span><span lang=EN-US style='font-family:"Courier New",serif'>gdb</span><span class=xapple-converted-space><span lang=EN-US style='font-family:"Ericsson Hilda",serif'> </span></span><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>and verified that having Defs causes GlobalISel to include<span class=xapple-converted-space> </span></span><span lang=EN-US style='font-family:"Courier New",serif'>CCReg</span><span class=xapple-converted-space><span lang=EN-US style='font-family:"Ericsson Hilda",serif'> </span></span><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>in the<span class=xapple-converted-space> </span></span><span lang=EN-US>Types</span><span class=xapple-converted-space><span lang=EN-US style='font-family:"Ericsson Hilda",serif'> </span></span><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>field of the<span class=xapple-converted-space> </span></span><span lang=EN-US>TreePatternNode</span><span class=xapple-converted-space><span lang=EN-US style='font-family:"Ericsson Hilda",serif'> </span></span><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>corresponding to the instruction, which is what GlobalISel looks at to subsequently reject the pattern on basis that the instruction produces multiple results.</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US>But from your comment, I take it that the<span class=xapple-converted-space> </span>Defs</span><span class=xapple-converted-space><span lang=EN-US style='font-family:"Ericsson Hilda",serif'> </span></span><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>field should never be considered actual output, is that correct? If so, I find it strange that<span class=xapple-converted-space> </span></span><span lang=EN-US style='font-family:"Courier New",serif'>CodeGenDAGPatterns</span><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>, which parses the patterns, takes the CCReg into consideration as additional results. I am tempted to modify that part of the code, but maybe I’m missing some invariant that’s not immediately evident…</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US>Cheers,</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US>Gabriel</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US> </span><o:p></o:p></p></div></div><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><div><div><p class=MsoNormal style='margin-left:65.2pt'><b><span lang=EN-US>From:</span></b><span class=xapple-converted-space><span lang=EN-US> </span></span><span lang=EN-US>Dominik Montada<span class=xapple-converted-space> </span><a href="mailto:dominik.montada@hightec-rt.com"><span style='color:#954F72'><dominik.montada@hightec-rt.com></span></a><span class=xapple-converted-space> </span><br><b>Sent:</b><span class=xapple-converted-space> </span>den 4 juni 2020 14:51<br><b>To:</b><span class=xapple-converted-space> </span><a href="mailto:llvm-dev@lists.llvm.org"><span style='color:#954F72'>llvm-dev@lists.llvm.org</span></a><br><b>Cc:</b><span class=xapple-converted-space> </span>Gabriel Hjort Åkerlund<span class=xapple-converted-space> </span><a href="mailto:gabriel.hjort.akerlund@ericsson.com"><span style='color:#954F72'><gabriel.hjort.akerlund@ericsson.com></span></a><br><b>Subject:</b><span class=xapple-converted-space> </span>Re: [llvm-dev] Nested instruction patterns rejected by GlobalISel when having registers in Defs</span><o:p></o:p></p></div></div></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US> </span><o:p></o:p></p></div></div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:9.0pt;font-family:"Helvetica",sans-serif'>Hi Gabriel,</span><o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:9.0pt;font-family:"Helvetica",sans-serif'>I'm working on a downstream target which uses GlobalISel and we have many patterns with instructions that also define a system register as a side-effect and use them without any problem. Since CCReg is not an actual output of the instruction, but an implicit definition, GlobalISel should have no trouble with it, so I'm guessing your problem lies somewhere. Have you tried running the tablegen command manually and looked at the output there?</span><o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:9.0pt;font-family:"Helvetica",sans-serif'>The command is<span class=xapple-converted-space> </span></span><tt><span lang=EN-US style='font-size:10.0pt'>llvm-tblgen -gen-global-isel <couple of -I flags> <your_target>.td --write-if-changed --warn-on-skipped-patterns</span></tt><o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:9.0pt;font-family:"Helvetica",sans-serif'>I can't tell you exactly what -I flags you'll need but if you run ninja in verbose mode or look at the ninja build log, you should be able to see what is being used.</span><o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:9.0pt;font-family:"Helvetica",sans-serif'>Word of caution however: sometimes TableGen gives you a very clear error message indicating what is wrong, sometimes it gives you a very cryptic error message. And sometimes it doesn't even give you that and behave as if everything is a-ok while it still hasn't included your pattern. I have lost countless hours trying to debug TableGen patterns with GlobalISel and there's still a lot of stuff that GlobalISel unfortunately does not support yet in TableGen. So be prepared to write some C++ code for the unsupported cases for the moment.</span><o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:65.2pt'><span style='font-size:9.0pt;font-family:"Helvetica",sans-serif'>Cheers,</span><o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:65.2pt'><span style='font-size:9.0pt;font-family:"Helvetica",sans-serif'>Dominik</span><o:p></o:p></p></div><div><div><div><p class=MsoNormal style='margin-left:65.2pt'>Am 04.06.20 um 14:34 schrieb Gabriel Hjort Åkerlund via llvm-dev:<o:p></o:p></p></div></div></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US>Hi,</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US>I am in the process of porting our target to GlobalISel, and have encountered a problem. Nearly all instructions in our instruction set make modifications to a CC register, and hence are defined as follows:</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US>let ..., Defs = [CCReg] in</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US>def shfts_a32_imm7: Instruction<(outs OurRC:$dst), ...>;</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818'> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818'>What’s more, many of these instructions have patterns where the instruction itself appears inside a nested tree, e.g.:</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818'> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:10.0pt'>def Pat<(source pattern ...),</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:10.0pt'> <span class=xapple-converted-space> </span>(sext_a32 (INSERT_SUBREG (...), (shfts_a32_imm7 OurRC:$src, Imm7:$imm), ...>;</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818'> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818'>Now to the problem: When TableGen processes the instruction above, it includes the<span class=xapple-converted-space> </span></span><span lang=EN-US style='font-size:10.0pt'>CCReg</span><span class=xapple-converted-space><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818'> </span></span><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818'>in the<span class=xapple-converted-space> </span></span><span lang=EN-US style='font-size:10.0pt'>Defs</span><span class=xapple-converted-space><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818'> </span></span><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818'>field along with the registers appearing in<span class=xapple-converted-space> </span></span><span lang=EN-US style='font-size:10.0pt'>outs</span><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818'>, thereby indicating that shfts_a32_imm7 produces two results. Currently, the GlobalISel-backend in TableGen requires that nested instructions appearing in the output pattern produce exactly one result. Consequently, TableGen rejects many of our patterns. But in reality, the instruction really only produces a single result and therefore this pattern should be allowed.</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818'> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818'>So I wonder, how should registers appear in<span class=xapple-converted-space> </span></span><span lang=EN-US style='font-size:10.0pt'>Defs</span><span class=xapple-converted-space><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818'> </span></span><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818'>be treated? Are they equal to those appearing in<span class=xapple-converted-space> </span></span><span lang=EN-US style='font-size:10.0pt'>outs</span><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818'>, and therefore interchangeable, or is it valid to disambiguate between them and therefore modify TableGen to only consider<span class=xapple-converted-space> </span></span><span lang=EN-US style='font-size:10.0pt'>outs<span class=xapple-converted-space> </span></span><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818'>as the result of interest when processing the patterns?</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818'> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><b><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818'>Gabriel Hjort Åkerlund</span></b><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818'> </span><o:p></o:p></p></div></div><div><p class=MsoNormal style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:65.2pt'><span lang=EN-US> </span><o:p></o:p></p></div><pre style='margin-left:65.2pt'><span lang=EN-US>_______________________________________________</span><o:p></o:p></pre><pre style='margin-left:65.2pt'><span lang=EN-US>LLVM Developers mailing list</span><o:p></o:p></pre><pre style='margin-left:65.2pt'><a href="mailto:llvm-dev@lists.llvm.org"><span lang=EN-US style='color:#954F72'>llvm-dev@lists.llvm.org</span></a><o:p></o:p></pre><pre style='margin-left:65.2pt'><a href="https://protect2.fireeye.com/v1/url?k=52e18446-0c413e28-52e1c4dd-86b1886cfa64-f424e731a80348bd&q=1&e=238953c8-f0ec-4510-8c97-620bfb03d5be&u=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev"><span lang=EN-US style='color:#954F72'>https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</span></a><o:p></o:p></pre></blockquote><pre style='margin-left:65.2pt'>-- <o:p></o:p></pre><pre style='margin-left:65.2pt'>----------------------------------------------------------------------<o:p></o:p></pre><pre style='margin-left:65.2pt'>Dominik Montada Email: <a href="mailto:dominik.montada@hightec-rt.com"><span style='color:#954F72'>dominik.montada@hightec-rt.com</span></a><o:p></o:p></pre><pre style='margin-left:65.2pt'><span lang=EN-US>HighTec EDV-Systeme GmbH Phone: +49 681 92613 19</span><o:p></o:p></pre><pre style='margin-left:65.2pt'>Europaallee 19 Fax: +49-681-92613-26<o:p></o:p></pre><pre style='margin-left:65.2pt'>D-66113 Saarbrücken WWW: <a href="https://protect2.fireeye.com/v1/url?k=a0228059-fe823a37-a022c0c2-86b1886cfa64-48b7aa6978940111&q=1&e=238953c8-f0ec-4510-8c97-620bfb03d5be&u=http%3A%2F%2Fwww.hightec-rt.com%2F"><span style='color:#954F72'>http://www.hightec-rt.com</span></a><o:p></o:p></pre><pre style='margin-left:65.2pt'> <o:p></o:p></pre><pre style='margin-left:65.2pt'><span lang=EN-US>Managing Director: Vera Strothmann</span><o:p></o:p></pre><pre style='margin-left:65.2pt'><span lang=EN-US>Register Court: Saarbrücken, HRB 10445, VAT ID: DE 138344222</span><o:p></o:p></pre><pre style='margin-left:65.2pt'><span lang=EN-US> </span><o:p></o:p></pre><pre style='margin-left:65.2pt'><span lang=EN-US>This e-mail may contain confidential and/or privileged information. If</span><o:p></o:p></pre><pre style='margin-left:65.2pt'><span lang=EN-US>you are not the intended recipient please notify the sender immediately</span><o:p></o:p></pre><pre style='margin-left:65.2pt'><span lang=EN-US>and destroy this e-mail. Any unauthorised copying, disclosure or</span><o:p></o:p></pre><pre style='margin-left:65.2pt'><span lang=EN-US>distribution of the material in this e-mail is strictly forbidden.</span><o:p></o:p></pre><pre style='margin-left:65.2pt'>--- <o:p></o:p></pre></div></blockquote><pre style='margin-left:65.2pt;font-variant-caps: normal;text-align:start;word-spacing:0px'>-- <o:p></o:p></pre><pre style='margin-left:65.2pt'>----------------------------------------------------------------------<o:p></o:p></pre><pre style='margin-left:65.2pt'>Dominik Montada Email: <a href="mailto:dominik.montada@hightec-rt.com"><span style='color:#954F72'>dominik.montada@hightec-rt.com</span></a><o:p></o:p></pre><pre style='margin-left:65.2pt'><span lang=EN-US>HighTec EDV-Systeme GmbH Phone: +49 681 92613 19</span><o:p></o:p></pre><pre style='margin-left:65.2pt'>Europaallee 19 Fax: +49-681-92613-26<o:p></o:p></pre><pre style='margin-left:65.2pt'>D-66113 Saarbrücken WWW: <a href="https://protect2.fireeye.com/v1/url?k=b7cd53d5-e96de9bb-b7cd134e-861d41abace8-5636b949d44c6f9b&q=1&e=9aff5cfa-72fd-4986-af7c-78b27f9ea1e8&u=http%3A%2F%2Fwww.hightec-rt.com%2F"><span style='color:#954F72'>http://www.hightec-rt.com</span></a><o:p></o:p></pre><pre style='margin-left:65.2pt'> <o:p></o:p></pre><pre style='margin-left:65.2pt'><span lang=EN-US>Managing Director: Vera Strothmann</span><o:p></o:p></pre><pre style='margin-left:65.2pt'><span lang=EN-US>Register Court: Saarbrücken, HRB 10445, VAT ID: DE 138344222</span><o:p></o:p></pre><pre style='margin-left:65.2pt'><span lang=EN-US> </span><o:p></o:p></pre><pre style='margin-left:65.2pt'><span lang=EN-US>This e-mail may contain confidential and/or privileged information. If</span><o:p></o:p></pre><pre style='margin-left:65.2pt'><span lang=EN-US>you are not the intended recipient please notify the sender immediately</span><o:p></o:p></pre><pre style='margin-left:65.2pt'><span lang=EN-US>and destroy this e-mail. Any unauthorised copying, disclosure or</span><o:p></o:p></pre><pre style='margin-left:65.2pt'><span lang=EN-US>distribution of the material in this e-mail is strictly forbidden.</span><o:p></o:p></pre><pre style='margin-left:65.2pt'><span lang=EN-US>--- </span><o:p></o:p></pre><div><p class=MsoNormal style='margin-left:65.2pt'><span lang=EN-US style='font-size:9.0pt;font-family:"Helvetica",sans-serif'>_______________________________________________<br>LLVM Developers mailing list<br></span><a href="mailto:llvm-dev@lists.llvm.org"><span lang=EN-US style='font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#954F72'>llvm-dev@lists.llvm.org</span></a><span lang=EN-US style='font-size:9.0pt;font-family:"Helvetica",sans-serif'><br></span><a href="https://protect2.fireeye.com/v1/url?k=b3d033f0-ed70899e-b3d0736b-861d41abace8-91f0c9908116c6fb&q=1&e=9aff5cfa-72fd-4986-af7c-78b27f9ea1e8&u=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev"><span lang=EN-US style='font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#954F72'>https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</span></a><o:p></o:p></p></div></div></blockquote></div></div></div></blockquote></div></div></div></blockquote></div><p class=MsoNormal style='margin-left:65.2pt'><o:p> </o:p></p></div></body></html>