<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)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"MS Gothic";
panose-1:2 11 6 9 7 2 5 8 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:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@MS Gothic";
panose-1:2 11 6 9 7 2 5 8 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"Meiryo UI";}
@font-face
{font-family:"\@Meiryo UI";}
/* 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;}
p.gmail-m-1259920849298943205gmaildefault, li.gmail-m-1259920849298943205gmaildefault, div.gmail-m-1259920849298943205gmaildefault
{mso-style-name:gmail-m_-1259920849298943205gmaildefault;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
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">For integer operations in particular, operation legalization (LegalizeDAG) has limited support, yes. That isn’t really a fundamental limitation; the infrastructure is generally okay with rewriting operations to use different (legal) types.
But in practice, we don’t support marking basic integer operations like “ADD/AND/OR/XOR” as Expand, and it would be painful to implement in SelectionDAG and DAGCombine because a bunch of places assume they’re legal. So in practice, a target that doesn’t have
i32 “ADD” should not mark i32 as a legal type.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If the only “i32” operation the target has is load/store, I’d recommend modeling an “i32” load as a load of two i16 values. You can either build these using custom lowering in SelectionDAG, or merge adjacent loads after isel. Existing
targets have instructions like this; for example, ldrd on ARM, ldp on AArch64.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Eli<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> <b>On Behalf Of
</b>Craig Topper via llvm-dev<br>
<b>Sent:</b> Thursday, February 6, 2020 11:43 PM<br>
<b>To:</b> Miguel Inigo J. Manalac <miguel.manalac@rldp.com.ph><br>
<b>Cc:</b> llvm-dev@lists.llvm.org<br>
<b>Subject:</b> [EXT] Re: [llvm-dev] LLVM Backend Legalize Phase<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">setOperationAction(Expand) won't split any operations into smaller types. It just rewrites some operations in terms of other operations on the same type. And a lot of operations aren't supported as you've noticed as there is no realistic
way to do them using other operations on the same type<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">~Craig<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, Feb 6, 2020 at 11:26 PM Miguel Inigo J. Manalac via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-PH" style="font-family:"Meiryo UI",sans-serif;color:black">Hello Sebastien,</span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-PH" style="font-family:"Meiryo UI",sans-serif;color:black"> </span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-PH" style="font-family:"Meiryo UI",sans-serif;color:black">Thank you very much for the clarification. This would greatly help us in our development.</span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-PH" style="font-family:"Meiryo UI",sans-serif;color:black"> </span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-PH" style="font-family:"Meiryo UI",sans-serif;color:black">I have noticed that setOperationAction(Expand) does not always work, for these cases, does it automatically
mean that setOperationAction(Custom) should be used or not necessarily?</span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-PH" style="font-family:"Meiryo UI",sans-serif;color:black">Currently, we perform a pseudo instruction instead of setting it to custom.
</span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-PH" style="font-family:"Meiryo UI",sans-serif;color:black"> </span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-PH" style="font-family:"Meiryo UI",sans-serif;color:black">For example in the case of a load/store, 8 bits and 16 bits load/store can be natively performed but for
the 32 bits, we have to expand it into two 16 bits operations in a pseudo instruction. We have not yet implemented 64 bits load/store, should we continue using pseudo instruction for this considering that instead of expanding we need to load effective address
from memory and perform load/store 64 bits register with the loaded effective address?</span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-PH" style="font-family:"Meiryo UI",sans-serif;color:black"> </span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-PH" style="font-family:"Meiryo UI",sans-serif;color:black">Again, thank you for your help!</span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-PH" style="font-family:"Meiryo UI",sans-serif;color:black"> </span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-PH" style="font-family:"Meiryo UI",sans-serif;color:black">Best,</span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-PH" style="font-family:"Meiryo UI",sans-serif;color:black">Miguel</span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-PH" style="font-family:"Meiryo UI",sans-serif;color:black"> </span><span lang="EN-PH"><o:p></o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif"> Sebastien Le Duc [mailto:<a href="mailto:sleduc@kalray.eu" target="_blank">sleduc@kalray.eu</a>]
<br>
<b>Sent:</b> February 06, 2020 4:27 PM<br>
<b>To:</b> Miguel Inigo J. Manalac<br>
<b>Subject:</b> RE: [llvm-dev] LLVM Backend Legalize Phase</span><span lang="EN-PH"><o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-PH"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#1F497D">I think you can make the 32bit and 64bit types legal (using addRegisterClass) and use setOperationAction(Expand) for all the operations for which you
don’t have native support.</span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#1F497D"> </span><span lang="EN-PH"><o:p></o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif"> llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>]
<b>On Behalf Of </b>Miguel Inigo J. Manalac via llvm-dev<br>
<b>Sent:</b> Thursday, February 6, 2020 2:27 AM<br>
<b>To:</b> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<b>Subject:</b> [llvm-dev] LLVM Backend Legalize Phase</span><span lang="EN-PH"><o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <span lang="EN-PH"><o:p></o:p></span></p>
<div>
<div>
<div>
<div>
<p class="gmail-m-1259920849298943205gmaildefault" style="margin-bottom:11.25pt;line-height:14.65pt;vertical-align:baseline">
<span lang="EN-PH" style="font-size:11.5pt;font-family:"Verdana",sans-serif;color:black">Hello llvm-dev,</span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="gmail-m-1259920849298943205gmaildefault" style="margin-bottom:11.25pt;line-height:14.65pt;vertical-align:baseline">
<span lang="EN-PH" style="font-size:11.5pt;font-family:"Verdana",sans-serif;color:black"> </span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="gmail-m-1259920849298943205gmaildefault" style="margin-bottom:11.25pt;line-height:14.65pt;vertical-align:baseline">
<span lang="EN-PH" style="font-size:11.5pt;font-family:"Verdana",sans-serif;color:#242729">Our team is currently creating an LLVM backend for embedded systems. We're seeking for an advice on the best/correct way to implement our register classes in the Legalize
Phase. As an overview, our backend has 8-bit, 16-bit, 32-bit, and 64-bit register classes. Our instruction set consist mostly of 8-bit and 16-bit instructions. The 32-bit and 64-bit instructions are commonly used in memory access operations.
</span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="gmail-m-1259920849298943205gmaildefault" style="margin-bottom:11.25pt;line-height:14.65pt;vertical-align:baseline;box-sizing:border-box;font-stretch:normal;word-spacing:0px">
<span lang="EN-PH" style="font-size:11.5pt;font-family:"Verdana",sans-serif;color:#242729">The LLVM Backend reference we used is the AVR. In their implementation, 8-bit and 16-bit register classes were added with the addRegisterClass function (They only have
up to 16-bit registers) in their TargetLowering. With this, 32-bit and 64-bit operations are automatically split into its equivalent 8/16-bit operations in the DAG after the Legalize Phase.</span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="gmail-m-1259920849298943205gmaildefault" style="margin-bottom:11.25pt;line-height:14.65pt;vertical-align:baseline;box-sizing:border-box;font-stretch:normal;word-spacing:0px">
<span lang="EN-PH" style="font-size:11.5pt;font-family:"Verdana",sans-serif;color:#242729">For the LLVM Backend we are currently developing, in one hand, adding the 32-bit and 64-bit register classes would output DAG nodes containing 32/64-bit operations. This
would require us to create pseudo instructions in the TableGen for expansion to its 8/16-bit equivalent operations. On the other hand, not adding these register classes would have the same behavior with the AVR.</span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="gmail-m-1259920849298943205gmaildefault" style="margin-bottom:11.25pt;line-height:14.65pt;vertical-align:baseline;box-sizing:border-box;font-stretch:normal;word-spacing:0px">
<span lang="EN-PH" style="font-size:11.5pt;font-family:"Verdana",sans-serif;color:#242729">We are unaware of the consequences of both cases. We have only tested this with load and store operations for now. We have not verified if the DAG output are also correct
for other operations. What should we consider in deciding what to use in our implementation?</span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="gmail-m-1259920849298943205gmaildefault" style="margin-bottom:11.25pt;line-height:14.65pt;vertical-align:baseline;box-sizing:border-box;font-stretch:normal;word-spacing:0px">
<span lang="EN-PH" style="font-size:11.5pt;font-family:"Verdana",sans-serif;color:#242729">Thank you very much in advance for your efforts and help!</span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="gmail-m-1259920849298943205gmaildefault" style="margin-bottom:11.25pt;line-height:14.65pt;vertical-align:baseline;box-sizing:border-box;font-stretch:normal;word-spacing:0px">
<span lang="EN-PH" style="font-size:11.5pt;font-family:"Verdana",sans-serif;color:#242729">Best,</span><span lang="EN-PH"><o:p></o:p></span></p>
<p class="gmail-m-1259920849298943205gmaildefault" style="margin-bottom:11.25pt;line-height:14.65pt;vertical-align:baseline;box-sizing:border-box;font-stretch:normal;word-spacing:0px">
<span lang="EN-PH" style="font-size:11.5pt;font-family:"Verdana",sans-serif;color:#242729">Igie</span><span lang="EN-PH"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-PH">JAPANESE:
</span><span lang="JA" style="font-family:"MS Gothic";mso-fareast-language:JA">このメールは、宛先に書かれている方のみに送信することを意図しております。誤ってそれ以外の方に送信された場合は、申し訳ございませんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願いいたします。また、コンピュータ・ウィルスの混入等によってメールの欠落・不整合・遅滞等が発生し、何らのご不便をおかけすることが生じても弊社はその責任を負いません。</span><span lang="EN-PH">
ENGLISH: This e-mail is intended for the person(s) to which it is addressed. If you have received it by mistake, please notify the sender and delete the received email. In addition, our company shall not assume any responsibility even if it causes any inconvenience,
such as loss of mail, inconsistencies, delays, etc., due to the inclusion of computer viruses.
<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-PH">JAPANESE: </span><span style="font-family:"MS Gothic"">このメールは、宛先に書かれている方のみに送信することを意図しております。誤ってそれ以外の方に送信された場合は、申し訳ございませんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願いいたします。また、コンピュータ・ウィルスの混入等によってメールの欠落・不整合・遅滞等が発生し、何らのご不便をおかけすることが生じても弊社はその責任を負いません。</span><span lang="EN-PH">
ENGLISH: This e-mail is intended for the person(s) to which it is addressed. If you have received it by mistake, please notify the sender and delete the received email. In addition, our company shall not assume any responsibility even if it causes any inconvenience,
such as loss of mail, inconsistencies, delays, etc., due to the inclusion of computer viruses.
<o:p></o:p></span></p>
</div>
<p class="MsoNormal">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</body>
</html>