<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>Hi Hjort,<br>
</p>
<p>I'm not sure whether your use-case is supported (yet) in TableGen
with GlobalISel, so one workaround would be to implement the
instruction selection for G_LOAD in your
<Target>InstructionSelector.cpp::select method. You could
take a look at the AArch64 or AMDGPU InstructionSelector.cpp if
you need some more complex examples on how to do that.<br>
</p>
<p>AFAIU the GlobalISel TableGen backend isn't as mighty yet so a
lot of the more niche-cases need to be implemented manually at the
moment.</p>
<p>I'm sure the GlobalISel maintainers can give you a more detailed
answer and maybe even a solution for your use-case. For the
meantime though I hope that this helps a bit.<br>
</p>
<p>Cheers,</p>
<p>Dominik<br>
</p>
<div class="moz-cite-prefix">Am 25.08.20 um 08:52 schrieb Gabriel
Hjort Åkerlund via llvm-dev:<br>
</div>
<blockquote type="cite"
cite="mid:HE1PR07MB314771B7A2EA25747461E655BA570@HE1PR07MB3147.eurprd07.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<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:"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;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Ericsson Hilda",serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@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]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda",serif" lang="EN-US">We have a special
architecture where i24 is a legal data type, and where 16
bits – not 8 bits – is considered a byte. Thus, the smallest
addressable unit is 16 bits, which in combination with i24
causes problems during matching in global-isel. Let us
assume that we have the following pattern:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda",serif" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Courier
New";color:black" lang="EN-US"> (ld:{ *:[i24] }
aN32_0_7:{ *:[i32]
}:$addr)<<P:Predicate_unindexedload>><<P:Predicate_load>></span><span
style="font-size:12.0pt;font-family:"Courier
New";color:black;mso-fareast-language:SV" lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda",serif" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda",serif" lang="EN-US">for which the matching table
looks as follows:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda",serif" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier
New"" lang="EN-US"> ...<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Courier
New";color:black" lang="EN-US">
GIM_CheckMemorySizeEqualToLLT, /*MI*/0, /*MMO*/0,
/*OpIdx*/0,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Courier
New";color:black" lang="EN-US">
GIM_CheckAtomicOrdering, /*MI*/0,
/*Order*/(int64_t)AtomicOrdering::NotAtomic,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Courier
New";color:black" lang="EN-US"> // MIs[0] addr<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Courier
New";color:black" lang="EN-US"> GIM_CheckPointerToAny,
/*MI*/0, /*Op*/1, /*SizeInBits*/32,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Courier
New";color:black" lang="EN-US">
GIM_CheckRegBankForClass, /*MI*/0, /*Op*/1,
/*RC*/PHX::aN32_0_7RegClassID,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier
New"" lang="EN-US"> ...<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda",serif" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda",serif" lang="EN-US">Because 24 bits is not a
multiple of 16, we load 2 “bytes” aligned at 1. Hence, the
table above is expected to match:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda",serif" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier
New"" lang="EN-US"> %1(s24) = G_LOAD %0 :: (load 2,
align 1)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda",serif" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda",serif" lang="EN-US">However, this is always
rejected due to:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda",serif" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Courier
New";color:black" lang="EN-US">
GIM_CheckMemorySizeEqualToLLT, /*MI*/0, /*MMO*/0,
/*OpIdx*/0,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Courier
New";color:black" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda",serif" lang="EN-US">which checks whether the
size of the result (24 bits) is equal to the size of the
memory size (32 bits), which naturally is false.</span><span
style="font-family:"Ericsson Hilda",serif"
lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda",serif" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda",serif" lang="EN-US">A simple fix would be to
simply remove the check, but then there is no check ensuring
that the result of the source pattern matches the result of
the destination pattern. Also, I get the feeling that there
are underlying assumptions surrounding G_LOAD that you
either load data of equal or greater size (which is then
extended), but never of smaller size (as in this case).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda",serif" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda",serif" lang="EN-US">What is the proper fix to
this problem? As I see it, either we allow G_LOAD to load
smaller sizes and patch the code impacted by this, or we
patch TableGen to generate code that allows such matches.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda",serif" lang="EN-US">We could also try to promote
i24 to i32, but that would involve modifying a lot of the
existing patterns we have (and i24 is anyhow a legal size in
our architecture).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda",serif" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda",serif" lang="EN-US">Best regards, <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda",serif" lang="EN-US">Gabriel Hjort Åkerlund<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
----------------------------------------------------------------------
Dominik Montada Email: <a class="moz-txt-link-abbreviated" href="mailto:dominik.montada@hightec-rt.com">dominik.montada@hightec-rt.com</a>
HighTec EDV-Systeme GmbH Phone: +49 681 92613 19
Europaallee 19 Fax: +49-681-92613-26
D-66113 Saarbrücken WWW: <a class="moz-txt-link-freetext" href="http://www.hightec-rt.com">http://www.hightec-rt.com</a>
Managing Director: Vera Strothmann
Register Court: Saarbrücken, HRB 10445, VAT ID: DE 138344222
This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient please notify the sender immediately
and destroy this e-mail. Any unauthorised copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
--- </pre>
</body>
</html>