<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 2/14/2017 3:27 AM, Stephen Rogers
via llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:CAMF8pPHeCY-P=cNcP2OQU3Va1pvMQQVzHWhmRQsTk9M+wbY7QQ@mail.gmail.com"
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'__divdi3', Register:i64
%reg0, Register:i64 %reg1, RegisterMask:Untyped, t48:1<br>
t51: ch,glue = callseq_end t50,
TargetConstant:i32<0>,
TargetExternalSymbol:i32'__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>
"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.<br>
<br>
-Eli<br>
<pre class="moz-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>
</body>
</html>