<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-2022-jp">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 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";
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"MS PGothic";
panose-1:2 11 6 0 7 2 5 8 2 4;}
@font-face
{font-family:"\@MS PGothic";
panose-1:2 11 6 0 7 2 5 8 2 4;}
@font-face
{font-family:"\@Meiryo UI";
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* 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;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-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:12.0pt;
font-family:"MS PGothic","sans-serif";}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Meiryo UI","sans-serif";
color:black;
font-weight:normal;
font-style:normal;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Meiryo UI","sans-serif";
color:black;
font-weight:normal;
font-style:normal;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Meiryo UI","sans-serif";
color:black;
font-weight:normal;
font-style:normal;}
p.Reply, li.Reply, div.Reply
{mso-style-name:Reply;
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:black;
mso-fareast-language:EN-US;}
.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;}
/* List Definitions */
@list l0
{mso-list-id:1531215443;
mso-list-type:hybrid;
mso-list-template-ids:-502488666 -1403343686 873005059 873005061 873005057 873005059 873005061 873005057 873005059 873005061;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Meiryo UI","sans-serif";
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l1
{mso-list-id:1753773297;
mso-list-template-ids:439501618;}
@list l1:level1
{mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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-PH" link="blue" vlink="purple">
<div class="WordSection1">
<p class="Reply"><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:windowtext">Hi llvm-dev,<o:p></o:p></span></p>
<p class="Reply"><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif""><o:p> </o:p></span></p>
<p class="Reply"><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif"">>>
</span><span lang="EN-US">The CopyFromReg->CopyToReg->CopyFromReg sequence doesn$B!G(Bt have the chains set correctly: the second CopyFromReg$B!G(Bs input chain isn$B!G(Bt connected to the CopyToReg$B!G(Bs output chain. (This appears to be the same problem in both graphs.)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:black">The DAG mentioned was generated by the SelectionDAGBuilder and as much as possible, we only modify the files within our target so I tried the next suggestion.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:black">>></span><span lang="EN-US" style="mso-fareast-language:EN-US"> Subregisters need to be listed in your RegisterInfo.td. If they are listed correctly, that should
be enough to avoid allocating overlapping registers in the register allocator.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:black">Although we have set the subregisters correctly in the RegisterInfo, subregisters of subregisters are not automatically listed which caused the overlapping. This
was solved by declaring subregisters of subregisters as Aliases.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:black">With this solution, The target now generates assembly for the function as expected. Special thanks to Eli for the help!<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:black">The problem now is, during function call, there is a CopyToReg(ER0(16-bit Reg), FrameIndex) generated, saving the pointer to the i64 return value memory location
in int form into a register. The plan is to extract the frame address and offset from the FrameIndex node and perform CopyToReg(ER0, (frame address + offset)).
<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo2"><![if !supportLists]><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:black"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:black">These DAG nodes are being created in LowerCall when the isSRet flag is true for an argument. Is it ideal to do it here or are there other better methods?
The main goal here is to expand FrameIndex node into an add(frame address, offset) node<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo2"><![if !supportLists]><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:black"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:black">I am currently having a hard time extracting the offset in the FrameIndex node. I have also read (From $B!H(BUsing frameindex in a pattern$B!I(B llvm-dev archive,
referring to the Sparc target) that adding frameindex into the def addr : Complex Pattern<$B!D(B,$B!I(BSelectAddr$B!I(B,$B!D(B> would only translate it into a targetframeindex with an offset of 0.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo2"><![if !supportLists]><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:black"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:black">In the AVR target, the ISD::FrameIndex has a custom select transforming it into an AVR:FRMIDX node and then later processed in the eliminateFrameIndex.
Is this equivalent to the process I am trying to do? <o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo2"><![if !supportLists]><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:black"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:black">What is the expected output process for a FrameIndex node when selected in ISelDAGToDAG? This node does not usually get selected for load/store operations.
What I understand is for load/store it contains information about address where to load from/store to.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:black">Thanks in advance!<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:black">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Meiryo UI","sans-serif";color:black">Miguel<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Eli Friedman [mailto:efriedma@quicinc.com]
<br>
<b>Sent:</b> February 15, 2020 4:56 AM<br>
<b>To:</b> Miguel Inigo J. Manalac; llvm-dev<br>
<b>Subject:</b> RE: [llvm-dev] Function Return Legalization<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="Reply"><span lang="EN-US">The CopyFromReg->CopyToReg->CopyFromReg sequence doesn$B!G(Bt have the chains set correctly: the second CopyFromReg$B!G(Bs input chain isn$B!G(Bt connected to the CopyToReg$B!G(Bs output chain. (This appears to be the same problem in both graphs.)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Subregisters need to be listed in your RegisterInfo.td. If they are listed correctly, that should be enough to avoid allocating overlapping registers in the register allocator.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">-Eli<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<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">From:</span></b><span lang="EN-US"> Miguel Inigo J. Manalac <miguel.manalac@rldp.com.ph>
<br>
<b>Sent:</b> Friday, February 14, 2020 12:15 AM<br>
<b>To:</b> Eli Friedman <efriedma@quicinc.com>; llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> [EXT] RE: [llvm-dev] Function Return Legalization<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">Hi,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">After removing support for the i64 type in the *CallingConv.td, sret-demotion is performed and we now have a store<(store 8, align 1)> DAG node being generated. Please refer
to the attached dag_funcret.pdf DAG visualization.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">My understanding is that, the second operand(CopyFromReg->Register %1, Register %0 back-up) in the store node is the memory location allocated for the i64 type return. Unfortunately,
this register is killed in the live variable analysis and makes the Register %0 the second operand. The Register %0 is overwritten during the processing of the function which makes the store node have an incorrect address as the second operand.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">I have also tried implementing SRET processing similar to x86<span lang="JA">$B!G(B</span>s implementation, this saves the Register %0 value into another register but it is stored
after the store node (starting from the EntryToken). Refer to dag_sret_proc.pdf for the DAG visualization for this.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">sret-demotion automatically sets er0(16-bit register, copied into Register %0) as a livein function argument containing the return memory location in LowerFormalArguments. er0
is a sub register of the qr0(i64 register) used in the processing. I think I was not able to inform the backend that if qr0 is modified, er0 is modified as well. Is there a way to do this?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">What classes/functions should I look into so that Register %1 will not be killed?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">I am considering to create a custom select function for ISD::STORE but I am worried that most probably i64 function ret is not the only process that would generate this kind
of store node.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">Thank you very much for your help and time!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">Miguel<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Eli Friedman [<a href="mailto:efriedma@quicinc.com">mailto:efriedma@quicinc.com</a>]
<br>
<b>Sent:</b> February 13, 2020 9:46 AM<br>
<b>To:</b> Miguel Inigo J. Manalac; llvm-dev<br>
<b>Subject:</b> RE: [llvm-dev] Function Return Legalization<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">LLVM calls a pointer that$B!G(Bs used to return a value indirectly, like you$B!G(Bre describing, an $B!H(Bsret$B!I(B argument. There are sort of two ways to go about generating one. First, you can edit
the call lowering code in clang (clang/lib/CodeGen/TargetInfo.cpp) so the pointer is represented explicitly in IR. Second, you can make the target-independent backend code generate an sret argument in SelectionDAG, by making your target$B!G(Bs $B!H(BCanLowerReturn$B!I(B
return false.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Probably making CanLowerReturn return false for i64 makes sense for your target. If you$B!G(Bre using TableGen$B!G(Bed calling conventions (*CallingConv.td), the TableGen$B!G(Bed code will handle
this automatically; otherwise, you can write it out explicitly in C++. If you want an example of how this works in practice, try something like $B!H(Becho 'define i128 @foo() { ret i128 3 }' | llc -mtriple=i686$B!I(B.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">If you need to stick the sret pointer into a special register, you can use CCIfSRet in TableGen. (Or if you$B!G(Bre not using a TableGen$B!G(Bed calling convention, you can check IsSRet in C++.)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">-Eli<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<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">From:</span></b><span lang="EN-US"> llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org">llvm-dev-bounces@lists.llvm.org</a>>
<b>On Behalf Of </b>Miguel Inigo J. Manalac via llvm-dev<br>
<b>Sent:</b> Wednesday, February 12, 2020 12:32 AM<br>
<b>To:</b> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<b>Subject:</b> [EXT] [llvm-dev] Function Return Legalization<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">Hi All,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">In the target we are implementing, function return for i64 and f64 types has a different processing.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">For types i8 to i32, and f32, the return values are stored in their designated return registers (like how other targets does it).
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">For i64 and f64 types, in the function call, after pushing the function parameters into the stack, the address of the allocated return memory space is assigned to a 16-bit register
(In our case, ER0). This is done by assigning the frame pointer register into ER0 and then adding the offset to it. So the output assembly code would somewhat look like the following:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">Expected Target ASM output for i64 function call with i64 return type:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">1 push qr0 ;; 64-bit parameter pushed into the stack<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">2 mov er0, fp ;; Assign the frame pointer into er0<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">3 add er0, #-32 ;; Add the frame pointer offset to er0<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">4 bl _fn ;; Function call fn<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">5 add sp, #8 ;; SP adjustment<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">In function fn:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">1 ;; function prologue processing here...<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">2 mov er8, er0 ;; frame pointer location of retval is transferred to er8 (will be used at line 4)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">3 ;; function processing here... Assuming that the i64 value to be returned is stored at qr0...<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">4 lea [er8] ;; i64 return processing starts here. Load effective address from [er8]<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">5 st qr0, [ea] ;; Store the i64 value into the effective address memory location.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">6 ;; function epilogue processing here...<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">From my investigations so far, i64 types should call a custom function in the calling convention for processing this return type. Also, that LowerCall should be modified to
have the assigning of frame pointer into er0 and that LowerReturn should be modified in order to store qr0 into the effective address. Please correct me if I</span><span lang="JA" style="font-family:"MS PGothic","sans-serif";color:black">$B!G(B</span><span style="font-family:"Meiryo UI","sans-serif";color:black">m
wrong.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">My questions are:<o:p></o:p></span></p>
<ol style="margin-top:0cm" start="1" type="1">
<li class="MsoNormal" style="color:black;mso-list:l1 level1 lfo1"><span style="font-family:"Meiryo UI","sans-serif"">Are there any target examples that also has this kind of behavior? If there are please let me know so I could study on it.<o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-list:l1 level1 lfo1"><span style="font-family:"Meiryo UI","sans-serif"">Where does the assigning of frame pointer+offset(frame index?) fall? I am currently suspecting that it should be in the LowerCall function.
<o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-list:l1 level1 lfo1"><span style="font-family:"Meiryo UI","sans-serif"">If my assumption that question #2 falls in LowerCall function is correct, how do I retrieve the created frame index from the LowerCall function
in the LowerReturn function?<o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-list:l1 level1 lfo1"><span style="font-family:"Meiryo UI","sans-serif"">I also suspect that the affected functions are not limited to LowerCall and LowerReturn, if you have suggestions on which ISelLowering Class
functions I should investigate on, please let me know.<o:p></o:p></span></li></ol>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">Thank you very much in advance for your help!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">Sincerely,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Meiryo UI","sans-serif";color:black">Miguel Inigo J. Manalac<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"MS PGothic","sans-serif"">JAPANESE:
</span><span lang="JA" style="font-size:12.0pt;font-family:"MS PGothic","sans-serif"">$B$3$N%a!<%k$O!"08@h$K=q$+$l$F$$$kJ}$N$_$KAw?.$9$k$3$H$r0U?^$7$F$*$j$^$9!#8m$C$F$=$l0J30$NJ}$KAw?.$5$l$?>l9g$O!"?=$7Lu$4$6$$$^$;$s$,!"Aw?.<T$^$G$*CN$i$;$$$?$@$-!"<u?.$5$l$?%a!<%k$r:o=|$7$F$$$?$@$-$^$9$h$&$*4j$$$$$?$7$^$9!#$^$?!"%3%s%T%e!<%?!&%&%#%k%9$N:.F~Ey$K$h$C$F%a!<%k$N7gMn!&IT@09g!&CYBZEy$,H/@8$7!"2?$i$N$4ITJX$r$*$+$1$9$k$3$H$,@8$8$F$bJ@<R$O$=$N@UG$$rIi$$$^$;$s!#(B</span><span lang="JA" style="font-size:12.0pt;font-family:"MS PGothic","sans-serif"">
</span><span style="font-size:12.0pt;font-family:"MS PGothic","sans-serif"">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 style="font-size:12.0pt;font-family:"MS PGothic","sans-serif"">JAPANESE:
</span><span lang="JA" style="font-size:12.0pt;font-family:"MS PGothic","sans-serif"">$B$3$N%a!<%k$O!"08@h$K=q$+$l$F$$$kJ}$N$_$KAw?.$9$k$3$H$r0U?^$7$F$*$j$^$9!#8m$C$F$=$l0J30$NJ}$KAw?.$5$l$?>l9g$O!"?=$7Lu$4$6$$$^$;$s$,!"Aw?.<T$^$G$*CN$i$;$$$?$@$-!"<u?.$5$l$?%a!<%k$r:o=|$7$F$$$?$@$-$^$9$h$&$*4j$$$$$?$7$^$9!#$^$?!"%3%s%T%e!<%?!&%&%#%k%9$N:.F~Ey$K$h$C$F%a!<%k$N7gMn!&IT@09g!&CYBZEy$,H/@8$7!"2?$i$N$4ITJX$r$*$+$1$9$k$3$H$,@8$8$F$bJ@<R$O$=$N@UG$$rIi$$$^$;$s!#(B</span><span style="font-size:12.0pt;font-family:"MS PGothic","sans-serif"">
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>
</div>
</div>
JAPANESE: $B$3$N%a!<%k$O!"08@h$K=q$+$l$F$$$kJ}$N$_$KAw?.$9$k$3$H$r0U?^$7$F$*$j$^$9!#8m$C$F$=$l0J30$NJ}$KAw?.$5$l$?>l9g$O!"?=$7Lu$4$6$$$^$;$s$,!"Aw?.<T$^$G$*CN$i$;$$$?$@$-!"<u?.$5$l$?%a!<%k$r:o=|$7$F$$$?$@$-$^$9$h$&$*4j$$$$$?$7$^$9!#$^$?!"%3%s%T%e!<%?!&%&%#%k%9$N:.F~Ey$K$h$C$F%a!<%k$N7gMn!&IT@09g!&CYBZEy$,H/@8$7!"2?$i$N$4ITJX$r$*$+$1$9$k$3$H$,@8$8$F$bJ@<R$O$=$N@UG$$rIi$$$^$;$s!#(B 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.
</body>
</html>