<div dir="ltr"><div><div><div>Thanks Eli,<br><br></div>This was exactly the problem. Using virtual registers for our function arguments has fixed it.<br><br></div>All the best,<br></div>Stephen<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 14 February 2017 at 18:21, Friedman, Eli <span dir="ltr"><<a href="mailto:efriedma@codeaurora.org" target="_blank">efriedma@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
<div class="m_-4960430557076726196moz-cite-prefix">On 2/14/2017 3:27 AM, Stephen Rogers
via llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>Hi all,<br>
</div>
<div><br>
</div>
<span style="font-family:monospace,monospace"><font face="arial,helvetica,sans-serif">Our target does not have
native support for 64-bit integers, so we rely on library
calls for certain</font></span><span style="font-family:arial,helvetica,sans-serif"> operations
(like <span style="font-family:monospace,monospace">sdiv</span>).
We recently ran into a problem where these operations that
are expanded to library calls aren't maintaining the proper
ordering in relation to other chains in the DAG.</span><span style="font-family:monospace,monospace"><br>
<br>
</span></div>
<span style="font-family:monospace,monospace"><font face="arial,helvetica,sans-serif">The following snippet of a
DAG demonstrates the problem.</font><br>
</span>
<div>
<div>
<div><span style="font-family:monospace,monospace"><br>
t0: ch = EntryToken<br>
t2: i64,ch,glue = CopyFromReg t0, Register:i64 %reg0<br>
t4: i64,ch,glue = CopyFromReg t2:1, Register:i64
%reg1, t2:1<br>
t6: i64,ch,glue = CopyFromReg t4:1, Register:i64
%reg2, t4:1<br>
t8: i64,ch,glue = CopyFromReg t6:1, Register:i64
%reg3, t6:1<br>
t11: ch = CopyToReg t0, Register:i64 %vreg0, t2<br>
t13: ch = CopyToReg t0, Register:i64 %vreg1, t4<br>
t15: ch = CopyToReg t0, Register:i64 %vreg2, t8<br>
t26: ch = TokenFactor t11, t13, t15, t2:1, t4:1,
t6:1, t8:1<br>
<span style="color:rgb(255,0,0)">t16: i64 = sdiv
t2, t4</span><br>
<br>
</span></div>
<div><span style="font-family:monospace,monospace"><font face="arial,helvetica,sans-serif">Before legalization,
there is a single </font>sdiv<font face="arial,helvetica,sans-serif"> node. After
legalization, this has been expanded to a call
sequence:</font><br>
</span></div>
<div><span style="font-family:monospace,monospace"><br>
t0: ch = EntryToken<br>
t2: i64,ch,glue = CopyFromReg t0, Register:i64 %reg0<br>
t4: i64,ch,glue = CopyFromReg t2:1, Register:i64
%reg1, t2:1<br>
t6: i64,ch,glue = CopyFromReg t4:1, Register:i64
%reg2, t4:1<br>
t8: i64,ch,glue = CopyFromReg t6:1, Register:i64
%reg3, t6:1<br>
<span style="color:rgb(255,0,0)"> t46: ch,glue =
callseq_start t0, TargetConstant:i32<0><br>
t47: ch,glue = CopyToReg t46, Register:i64 %reg0, t2<br>
t48: ch,glue = CopyToReg t47, Register:i64 %reg1,
t4, t47:1<br>
t50: ch,glue = SHAVEISD::CALL t48,
TargetExternalSymbol:i32'__<wbr>divdi3', Register:i64
%reg0, Register:i64 %reg1, RegisterMask:Untyped, t48:1<br>
t51: ch,glue = callseq_end t50,
TargetConstant:i32<0>,
TargetExternalSymbol:i32'__<wbr>divdi3', t50:1<br>
t52: i64,ch,glue = CopyFromReg t51, Register:i64
%reg0, t51:1</span><br>
t11: ch = CopyToReg t0, Register:i64 %vreg0, t2<br>
t13: ch = CopyToReg t0, Register:i64 %vreg1, t4<br>
t15: ch = CopyToReg t0, Register:i64 %vreg2, t8<br>
t26: ch = TokenFactor t11, t13, t15, t2:1, t4:1,
t6:1, t8:1<br>
</span><br>
<span style="font-family:monospace,monospace"><font face="arial,helvetica,sans-serif">Since the </font>sdiv<font face="arial,helvetica,sans-serif"> node is not part of
a chain, the </font>EntryToken<font face="arial,helvetica,sans-serif"> is used as the
starting point of the chain for the library call. This
means that the ordering between the sequence of </font>CopyFromReg<font face="arial,helvetica,sans-serif"> nodes and the call
sequence can be changed. Specifically, we are seeing
the two copies from </font>%reg2<font face="arial,helvetica,sans-serif"> and </font>%reg3<font face="arial,helvetica,sans-serif"> being moved to
after the call sequence. This is a problem since the
library call clobbers both of these registers (since
they are caller-saved registers).<br>
</font></span></div>
</div>
</div>
</div>
</blockquote>
<br></div></div>
"CopyFromReg t0, Register:i64 %reg0" is your problem: as you've
discovered, you can't model function arguments like this. If you
look at the debug output for an in-tree target (e.g. 32-bit ARM),
you'll find that the CopyFromReg nodes for register arguments are
copies from virtual registers. See MachineFunction::addLiveIn.<span class="HOEnZb"><font color="#888888"><br>
<br>
-Eli<br>
<pre class="m_-4960430557076726196moz-signature" cols="72">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project</pre>
</font></span></div>
</blockquote></div><br></div>