<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=iso-8859-1"><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;}
@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;
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
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;
mso-fareast-language:SV;}
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;
mso-fareast-language:SV;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
mso-fareast-language:EN-US;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Ericsson Hilda";
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="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span style='font-family:"Ericsson Hilda"'>Hi Dominik,<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Ericsson Hilda"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Ericsson Hilda"'>Thanks for your reply.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Ericsson Hilda"'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda"'>In my case, the </span><span lang=EN-US style='font-family:"Courier New",serif'>Defs</span><span lang=EN-US style='font-family:"Ericsson Hilda"'> 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><span lang=EN-US style='font-family:"Courier New",serif'>gdb</span><span lang=EN-US style='font-family:"Ericsson Hilda"'> and verified that having Defs causes GlobalISel to include </span><span lang=EN-US style='font-family:"Courier New",serif'>CCReg</span><span lang=EN-US style='font-family:"Ericsson Hilda"'> in the </span><span lang=EN-US style='font-family:"Courier New",serif'>Types</span><span lang=EN-US style='font-family:"Ericsson Hilda"'> field of the </span><span lang=EN-US style='font-family:"Courier New",serif'>TreePatternNode</span><span lang=EN-US style='font-family:"Ericsson Hilda"'> corresponding to the instruction, which is what GlobalISel looks at to subsequently reject the pattern on basis that the instruction produces multiple results.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda"'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda"'>But from your comment, I take it that the </span><span lang=EN-US style='font-family:"Courier New",serif'>Defs</span><span lang=EN-US style='font-family:"Ericsson Hilda"'> field should never be considered actual output, is that correct? If so, I find it strange that </span><span lang=EN-US style='font-family:"Courier New",serif'>CodeGenDAGPatterns</span><span lang=EN-US style='font-family:"Ericsson Hilda"'>, 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…<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda"'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda"'>Cheers,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda"'>Gabriel<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda"'><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><b><span lang=EN-US style='mso-fareast-language:SV'>From:</span></b><span lang=EN-US style='mso-fareast-language:SV'> Dominik Montada <dominik.montada@hightec-rt.com> <br><b>Sent:</b> den 4 juni 2020 14:51<br><b>To:</b> llvm-dev@lists.llvm.org<br><b>Cc:</b> Gabriel Hjort Åkerlund <gabriel.hjort.akerlund@ericsson.com><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><span lang=EN-US><o:p> </o:p></span></p><p>Hi Gabriel,<span style='mso-fareast-language:SV'><o:p></o:p></span></p><p>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?<o:p></o:p></p><p>The command is <tt><span 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><p>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.<o:p></o:p></p><p>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.<o:p></o:p></p><p>Cheers,<o:p></o:p></p><p>Dominik<o:p></o:p></p><div><p class=MsoNormal>Am 04.06.20 um 14:34 schrieb Gabriel Hjort Åkerlund via llvm-dev:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>Hi,<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal><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><p class=MsoNormal><span lang=EN-US> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-family:"Courier New",serif'>let ..., Defs = [CCReg] in</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-family:"Courier New",serif'>def shfts_a32_imm7: Instruction<(outs OurRC:$dst), ...>;</span><o:p></o:p></p><p class=MsoNormal style='mso-line-height-alt:3.0pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV'> </span><o:p></o:p></p><p class=MsoNormal style='mso-line-height-alt:3.0pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV'>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><p class=MsoNormal style='mso-line-height-alt:3.0pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV'> </span><o:p></o:p></p><p class=MsoNormal style='mso-line-height-alt:3.0pt'><span lang=EN-US style='font-size:10.0pt'>def Pat<(source pattern ...),</span><o:p></o:p></p><p class=MsoNormal style='mso-line-height-alt:3.0pt'><span lang=EN-US style='font-size:10.0pt'> (sext_a32 (INSERT_SUBREG (...), (shfts_a32_imm7 OurRC:$src, Imm7:$imm), ...>;</span><o:p></o:p></p><p class=MsoNormal style='mso-line-height-alt:3.0pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV'> </span><o:p></o:p></p><p class=MsoNormal style='mso-line-height-alt:3.0pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV'>Now to the problem: When TableGen processes the instruction above, it includes the </span><span lang=EN-US style='font-size:10.0pt'>CCReg</span><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV'> in the </span><span lang=EN-US style='font-size:10.0pt'>Defs</span><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV'> field along with the registers appearing in </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;mso-fareast-language:SV'>, 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><p class=MsoNormal style='mso-line-height-alt:3.0pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV'> </span><o:p></o:p></p><p class=MsoNormal style='mso-line-height-alt:3.0pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV'>So I wonder, how should registers appear in </span><span lang=EN-US style='font-size:10.0pt'>Defs</span><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV'> be treated? Are they equal to those appearing in </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;mso-fareast-language:SV'>, and therefore interchangeable, or is it valid to disambiguate between them and therefore modify TableGen to only consider </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;mso-fareast-language:SV'>as the result of interest when processing the patterns?</span><o:p></o:p></p><p class=MsoNormal style='mso-line-height-alt:3.0pt'><span lang=EN-US style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV'> </span><o:p></o:p></p><p class=MsoNormal style='mso-line-height-alt:3.0pt'><b><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV'>Gabriel Hjort Åkerlund</span></b><o:p></o:p></p><p class=MsoNormal style='mso-line-height-alt:3.0pt'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV'> </span><o:p></o:p></p><p class=MsoNormal><span style='mso-fareast-language:SV'><br><br><o:p></o:p></span></p><pre>_______________________________________________<o:p></o:p></pre><pre>LLVM Developers mailing list<o:p></o:p></pre><pre><a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><o:p></o:p></pre><pre><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">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></pre></blockquote><pre>-- <o:p></o:p></pre><pre>----------------------------------------------------------------------<o:p></o:p></pre><pre>Dominik Montada Email: <a href="mailto:dominik.montada@hightec-rt.com">dominik.montada@hightec-rt.com</a><o:p></o:p></pre><pre>HighTec EDV-Systeme GmbH Phone: +49 681 92613 19<o:p></o:p></pre><pre>Europaallee 19 Fax: +49-681-92613-26<o:p></o:p></pre><pre>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">http://www.hightec-rt.com</a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Managing Director: Vera Strothmann<o:p></o:p></pre><pre>Register Court: Saarbrücken, HRB 10445, VAT ID: DE 138344222<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>This e-mail may contain confidential and/or privileged information. If<o:p></o:p></pre><pre>you are not the intended recipient please notify the sender immediately<o:p></o:p></pre><pre>and destroy this e-mail. Any unauthorised copying, disclosure or<o:p></o:p></pre><pre>distribution of the material in this e-mail is strictly forbidden.<o:p></o:p></pre><pre>--- <o:p></o:p></pre></div></body></html>