<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 03/07/2017 08:43 PM, Tim Shen via
llvm-commits wrote:<br>
</div>
<blockquote
cite="mid:CAG4ZjNnevLZs0of+4m-Kr4P-era5gdYjKK+bX_3npzNO45ag7Q@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">On Tue, Mar 7, 2017 at 6:21 PM Tim Shen <<a
moz-do-not-send="true" href="mailto:timshen@google.com">timshen@google.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr" class="gmail_msg">I found the problem. In the
patch, there is a check for isVarArg:</div>
<div dir="ltr" class="gmail_msg">
<div class="gmail_msg">
<div class="gmail_msg"> bool HasParameterArea =
!isELFv2ABI || isVarArg || CallConv ==
CallingConv::Fast;</div>
</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
</div>
<div dir="ltr" class="gmail_msg">
<div class="gmail_msg">In our internal case, the callee is
indeed a var arg function, but the call is through a
function pointer. I think this optimization should be
off for indirect call as well.</div>
</div>
</blockquote>
<div><br>
</div>
<div>Oops, we had a C cast from a var arg function pointer
into a non-var-arg function pointer in the source. We
deserve the UB :/.</div>
</div>
</div>
</blockquote>
<br>
Do you think that we should make Clang warn on this case? A user
might not realize that on some targets this is an ABI-incompatible
change.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CAG4ZjNnevLZs0of+4m-Kr4P-era5gdYjKK+bX_3npzNO45ag7Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>For this failure it's not the patch's fault. I'll revert
the revert and test it again.</div>
<div><br>
</div>
<div>Sorry for the disturbance!</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br
class="gmail_msg">
<div class="gmail_quote gmail_msg">
<div dir="ltr" class="gmail_msg">On Tue, Mar 7, 2017 at
2:37 PM Tim Shen <<a moz-do-not-send="true"
href="mailto:timshen@google.com" class="gmail_msg"
target="_blank">timshen@google.com</a>> wrote:<br
class="gmail_msg">
</div>
<blockquote class="gmail_quote gmail_msg" style="margin:0
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr" class="gmail_msg">Update:
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">The failure mode is that,
malloc(10) returns a bogus address,
like 0x3fff9cc60428. Normal addresses are
like 0x1003a00b980. Here malloc uses TCMalloc.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">Still looking.</div>
</div>
<br class="gmail_msg">
<div class="gmail_quote gmail_msg">
<div dir="ltr" class="gmail_msg">On Tue, Mar 7, 2017
at 9:40 AM Tim Shen <<a moz-do-not-send="true"
href="mailto:timshen@google.com" class="gmail_msg"
target="_blank">timshen@google.com</a>> wrote:<br
class="gmail_msg">
</div>
<blockquote class="gmail_quote gmail_msg"
style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr" class="gmail_msg">In an internal
function, I found the a very early instruction
modifies the first parameter (r3):<br
class="gmail_msg">
ld r3,-31576(r2)
<div class="gmail_msg"><br class="gmail_msg">
which immediately clobbers r3. Succeeding
operations on r3 causes a crash.<br
class="gmail_msg">
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">My guess would be this
function assumes the parameters are on the
stack, while the caller doesn't assume so.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">Still investigating.</div>
</div>
</div>
<br class="gmail_msg">
<div class="gmail_quote gmail_msg">
<div dir="ltr" class="gmail_msg">On Tue, Mar 7,
2017 at 1:59 AM Nemanja Ivanovic via
llvm-commits <<a moz-do-not-send="true"
href="mailto:llvm-commits@lists.llvm.org"
class="gmail_msg" target="_blank">llvm-commits@lists.llvm.org</a>>
wrote:<br class="gmail_msg">
</div>
<blockquote class="gmail_quote gmail_msg"
style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr" class="gmail_msg">
<div class="gmail_msg">
<div class="gmail_msg">Thanks Daniel and
Tim,<br class="gmail_msg">
<br class="gmail_msg">
</div>
It's certainly a curious thing that this
occurs. I am just curious, does this happen
at noopt or with optimization? The only
thing I can think of is that maybe this
stack frame reduction isn't valid if mem2reg
isn't run. But this is more or less a total
shot in the dark.<br class="gmail_msg">
<br class="gmail_msg">
</div>
</div>
<div dir="ltr" class="gmail_msg">Nemanja.<br
class="gmail_msg">
</div>
<div class="gmail_extra gmail_msg"><br
class="gmail_msg">
<div class="gmail_quote gmail_msg">On Tue, Mar
7, 2017 at 9:20 AM, Daniel Jasper <span
dir="ltr" class="gmail_msg"><<a
moz-do-not-send="true"
href="mailto:djasper@google.com"
class="gmail_msg" target="_blank">djasper@google.com</a>></span>
wrote:<br class="gmail_msg">
<blockquote class="gmail_quote gmail_msg"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div dir="ltr" class="gmail_msg">
<div class="gmail_extra gmail_msg">Just
FYI, Tim has reverted this patch and
is looking at reducing a test case. He
should have one tomorrow morning.</div>
<div class="gmail_extra gmail_msg"><br
class="gmail_msg">
</div>
<div class="gmail_extra gmail_msg">So
far, he found that the first parameter
is live but clobbered immediately in
some case.</div>
<div class="gmail_extra gmail_msg">Assembly:</div>
<div class="gmail_extra gmail_msg">ld
r3,-31576(r2)</div>
<div class="gmail_extra gmail_msg"><br
class="gmail_msg">
</div>
<div class="gmail_extra gmail_msg">(I
don't know what that means, but just
wanted to provide as much information
as I can, in case that makes it easy
for you to spot the bug)</div>
<div class="gmail_extra gmail_msg"><br
class="gmail_msg">
</div>
<div class="gmail_extra gmail_msg">Cheers,</div>
<div class="gmail_extra gmail_msg">Danie</div>
<div class="gmail_msg">
<div
class="m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405h5
gmail_msg">
<div class="gmail_extra gmail_msg"><br
class="gmail_msg">
<div class="gmail_quote gmail_msg">On
Tue, Mar 7, 2017 at 7:48 AM,
Daniel Jasper <span dir="ltr"
class="gmail_msg"><<a
moz-do-not-send="true"
href="mailto:djasper@google.com"
class="m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-cremed
m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-cremed
m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637cremed
gmail_msg" target="_blank">djasper@google.com</a>></span>
wrote:<br class="gmail_msg">
<blockquote class="gmail_quote
gmail_msg" style="margin:0px
0px 0px 0.8ex;border-left:1px
solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr"
class="gmail_msg">This seems
to be causing some
miscompiles. Working on a
test case.</div>
<div
class="m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-m_431023069260411042HOEnZb
gmail_msg">
<div
class="m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-m_431023069260411042h5
gmail_msg">
<div class="gmail_extra
gmail_msg"><br
class="gmail_msg">
<div class="gmail_quote
gmail_msg">On Thu, Mar
2, 2017 at 6:39 PM,
Nemanja Ivanovic via
llvm-commits <span
dir="ltr"
class="gmail_msg"><<a
moz-do-not-send="true" href="mailto:llvm-commits@lists.llvm.org"
class="m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-cremed
m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-cremed
m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637cremed
gmail_msg"
target="_blank">llvm-commits@lists.llvm.org</a>></span>
wrote:<br
class="gmail_msg">
<blockquote
class="gmail_quote
gmail_msg"
style="margin:0px
0px 0px
0.8ex;border-left:1px
solid
rgb(204,204,204);padding-left:1ex">Author:
nemanjai<br
class="gmail_msg">
Date: Thu Mar 2
11:38:59 2017<br
class="gmail_msg">
New Revision: 296771<br
class="gmail_msg">
<br
class="gmail_msg">
URL: <a
moz-do-not-send="true"
href="http://llvm.org/viewvc/llvm-project?rev=296771&view=rev"
rel="noreferrer"
class="m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-cremed
m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-cremed
m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637cremed
gmail_msg"
target="_blank">http://llvm.org/viewvc/llvm-project?rev=296771&view=rev</a><br
class="gmail_msg">
Log:<br
class="gmail_msg">
[PowerPC][ELFv2ABI]
Allocate parameter
area on-demand to
reduce stack frame
size<br
class="gmail_msg">
<br
class="gmail_msg">
This patch reduces
the stack frame size
by not allocating
the parameter area
if<br
class="gmail_msg">
it is not required.
In the current
implementation
LowerFormalArguments_64SVR4<br
class="gmail_msg">
already handles the
parameter area, but
LowerCall_64SVR4
does not<br
class="gmail_msg">
(when calculating
the stack frame
size). What this
patch does is make<br
class="gmail_msg">
LowerCall_64SVR4
consistent with
LowerFormalArguments_64SVR4.<br
class="gmail_msg">
<br
class="gmail_msg">
Committing on behalf
of Hiroshi Inoue.<br
class="gmail_msg">
<br
class="gmail_msg">
Differential
Revision: <a
moz-do-not-send="true"
href="https://reviews.llvm.org/D29881" rel="noreferrer"
class="m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-cremed
m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-cremed
m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637cremed
gmail_msg"
target="_blank">https://reviews.llvm.org/D29881</a><br
class="gmail_msg">
<br
class="gmail_msg">
Added:<br
class="gmail_msg">
llvm/trunk/test/CodeGen/PowerPC/stacksize.ll<br
class="gmail_msg">
Modified:<br
class="gmail_msg">
llvm/trunk/lib/Target/PowerPC/PPCISelLowering.cpp<br
class="gmail_msg">
<br
class="gmail_msg">
Modified:
llvm/trunk/lib/Target/PowerPC/PPCISelLowering.cpp<br
class="gmail_msg">
URL: <a
moz-do-not-send="true"
href="http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/PPCISelLowering.cpp?rev=296771&r1=296770&r2=296771&view=diff"
rel="noreferrer"
class="m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-cremed
m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-cremed
m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637cremed
gmail_msg"
target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/PPCISelLowering.cpp?rev=296771&r1=296770&r2=296771&view=diff</a><br
class="gmail_msg">
==============================================================================<br
class="gmail_msg">
---
llvm/trunk/lib/Target/PowerPC/PPCISelLowering.cpp
(original)<br
class="gmail_msg">
+++
llvm/trunk/lib/Target/PowerPC/PPCISelLowering.cpp
Thu Mar 2 11:38:59
2017<br
class="gmail_msg">
@@ -5147,10 +5147,30
@@ SDValue
PPCTargetLowering::LowerCall_64S<br
class="gmail_msg">
};<br
class="gmail_msg">
<br
class="gmail_msg">
const unsigned
NumGPRs =
array_lengthof(GPR);<br
class="gmail_msg">
- const unsigned
NumFPRs = 13;<br
class="gmail_msg">
+ const unsigned
NumFPRs =
useSoftFloat() ? 0 :
13;<br
class="gmail_msg">
const unsigned
NumVRs =
array_lengthof(VR);<br
class="gmail_msg">
const unsigned
NumQFPRs = NumFPRs;<br
class="gmail_msg">
<br
class="gmail_msg">
+ // On ELFv2, we
can avoid allocating
the parameter area
if all the arguments<br
class="gmail_msg">
+ // can be passed
to the callee in
registers.<br
class="gmail_msg">
+ // For the fast
calling convention,
there is another
check below.<br
class="gmail_msg">
+ // Note: keep
consistent with
LowerFormalArguments_64SVR4()<br
class="gmail_msg">
+ bool
HasParameterArea =
!isELFv2ABI ||
isVarArg || CallConv
==
CallingConv::Fast;<br
class="gmail_msg">
+ if
(!HasParameterArea)
{<br
class="gmail_msg">
+ unsigned
ParamAreaSize =
NumGPRs *
PtrByteSize;<br
class="gmail_msg">
+ unsigned
AvailableFPRs =
NumFPRs;<br
class="gmail_msg">
+ unsigned
AvailableVRs =
NumVRs;<br
class="gmail_msg">
+ unsigned
NumBytesTmp =
NumBytes;<br
class="gmail_msg">
+ for (unsigned i
= 0; i != NumOps;
++i) {<br
class="gmail_msg">
+ if
(Outs[i].Flags.isNest())
continue;<br
class="gmail_msg">
+ if
(CalculateStackSlotUsed(Outs[i].VT,
Outs[i].ArgVT,
Outs[i].Flags,<br
class="gmail_msg">
+
PtrByteSize,
LinkageSize,
ParamAreaSize,<br
class="gmail_msg">
+
NumBytesTmp,
AvailableFPRs,
AvailableVRs,<br
class="gmail_msg">
+
Subtarget.hasQPX()))<br
class="gmail_msg">
+
HasParameterArea =
true;<br
class="gmail_msg">
+ }<br
class="gmail_msg">
+ }<br
class="gmail_msg">
+<br
class="gmail_msg">
// When using the
fast calling
convention, we don't
provide backing for<br
class="gmail_msg">
// arguments that
will be in
registers.<br
class="gmail_msg">
unsigned
NumGPRsUsed = 0,
NumFPRsUsed = 0,
NumVRsUsed = 0;<br
class="gmail_msg">
@@ -5218,13 +5238,18
@@ SDValue
PPCTargetLowering::LowerCall_64S<br
class="gmail_msg">
<br
class="gmail_msg">
unsigned
NumBytesActuallyUsed
= NumBytes;<br
class="gmail_msg">
<br
class="gmail_msg">
- // The prolog
code of the callee
may store up to 8
GPR argument
registers to<br
class="gmail_msg">
+ // In the old
ELFv1 ABI,<br
class="gmail_msg">
+ // the prolog
code of the callee
may store up to 8
GPR argument
registers to<br
class="gmail_msg">
// the stack,
allowing va_start to
index over them in
memory if its
varargs.<br
class="gmail_msg">
// Because we
cannot tell if this
is needed on the
caller side, we have
to<br
class="gmail_msg">
// conservatively
assume that it is
needed. As such,
make sure we have at<br
class="gmail_msg">
// least enough
stack space for the
caller to store the
8 GPRs.<br
class="gmail_msg">
- // FIXME: On
ELFv2, it may be
unnecessary to
allocate the
parameter area.<br
class="gmail_msg">
- NumBytes =
std::max(NumBytes,
LinkageSize + 8 *
PtrByteSize);<br
class="gmail_msg">
+ // In the ELFv2
ABI, we allocate the
parameter area iff a
callee<br
class="gmail_msg">
+ // really
requires memory
operands, e.g. a
vararg function.<br
class="gmail_msg">
+ if
(HasParameterArea)<br
class="gmail_msg">
+ NumBytes =
std::max(NumBytes,
LinkageSize + 8 *
PtrByteSize);<br
class="gmail_msg">
+ else<br
class="gmail_msg">
+ NumBytes =
LinkageSize;<br
class="gmail_msg">
<br
class="gmail_msg">
// Tail call
needs the stack to
be aligned.<br
class="gmail_msg">
if
(getTargetMachine().Options.GuaranteedTailCallOpt
&&<br
class="gmail_msg">
@@ -5443,6 +5468,8
@@ SDValue
PPCTargetLowering::LowerCall_64S<br
class="gmail_msg">
if
(CallConv ==
CallingConv::Fast)<br
class="gmail_msg">
ComputePtrOff();<br
class="gmail_msg">
<br
class="gmail_msg">
+
assert(HasParameterArea
&&<br
class="gmail_msg">
+
"Parameter area
must exist to pass
an argument in
memory.");<br
class="gmail_msg">
LowerMemOpCallTo(DAG,
MF, Chain, Arg,
PtrOff, SPDiff,
ArgOffset,<br
class="gmail_msg">
true,
isTailCall, false,
MemOpChains,<br
class="gmail_msg">
TailCallArguments,
dl);<br
class="gmail_msg">
@@ -5528,6 +5555,8
@@ SDValue
PPCTargetLowering::LowerCall_64S<br
class="gmail_msg">
PtrOff =
DAG.getNode(ISD::ADD, dl, PtrVT, PtrOff, ConstFour);<br
class="gmail_msg">
}<br
class="gmail_msg">
<br
class="gmail_msg">
+
assert(HasParameterArea
&&<br
class="gmail_msg">
+
"Parameter area
must exist to pass
an argument in
memory.");<br
class="gmail_msg">
LowerMemOpCallTo(DAG,
MF, Chain, Arg,
PtrOff, SPDiff,
ArgOffset,<br
class="gmail_msg">
true,
isTailCall, false,
MemOpChains,<br
class="gmail_msg">
TailCallArguments,
dl);<br
class="gmail_msg">
@@ -5562,6 +5591,8
@@ SDValue
PPCTargetLowering::LowerCall_64S<br
class="gmail_msg">
// GPRs when
within range. For
now, we always put
the value in both<br
class="gmail_msg">
// locations
(or even all three).<br
class="gmail_msg">
if (isVarArg)
{<br
class="gmail_msg">
+
assert(HasParameterArea
&&<br
class="gmail_msg">
+
"Parameter area
must exist if we
have a varargs
call.");<br
class="gmail_msg">
// We could
elide this store in
the case where the
object fits<br
class="gmail_msg">
// entirely
in R registers.
Maybe later.<br
class="gmail_msg">
SDValue
Store =<br
class="gmail_msg">
@@ -5594,6 +5625,8
@@ SDValue
PPCTargetLowering::LowerCall_64S<br
class="gmail_msg">
if
(CallConv ==
CallingConv::Fast)<br
class="gmail_msg">
ComputePtrOff();<br
class="gmail_msg">
<br
class="gmail_msg">
+
assert(HasParameterArea
&&<br
class="gmail_msg">
+
"Parameter area
must exist to pass
an argument in
memory.");<br
class="gmail_msg">
LowerMemOpCallTo(DAG,
MF, Chain, Arg,
PtrOff, SPDiff,
ArgOffset,<br
class="gmail_msg">
true,
isTailCall, true,
MemOpChains,<br
class="gmail_msg">
TailCallArguments,
dl);<br
class="gmail_msg">
@@ -5614,6 +5647,8
@@ SDValue
PPCTargetLowering::LowerCall_64S<br
class="gmail_msg">
case MVT::v4i1:
{<br
class="gmail_msg">
bool IsF32 =
Arg.getValueType().getSimpleVT().SimpleTy == MVT::v4f32;<br
class="gmail_msg">
if (isVarArg)
{<br
class="gmail_msg">
+
assert(HasParameterArea
&&<br
class="gmail_msg">
+
"Parameter area
must exist if we
have a varargs
call.");<br
class="gmail_msg">
// We could
elide this store in
the case where the
object fits<br
class="gmail_msg">
// entirely
in R registers.
Maybe later.<br
class="gmail_msg">
SDValue
Store =<br
class="gmail_msg">
@@ -5646,6 +5681,8
@@ SDValue
PPCTargetLowering::LowerCall_64S<br
class="gmail_msg">
if
(CallConv ==
CallingConv::Fast)<br
class="gmail_msg">
ComputePtrOff();<br
class="gmail_msg">
<br
class="gmail_msg">
+
assert(HasParameterArea
&&<br
class="gmail_msg">
+
"Parameter area
must exist to pass
an argument in
memory.");<br
class="gmail_msg">
LowerMemOpCallTo(DAG,
MF, Chain, Arg,
PtrOff, SPDiff,
ArgOffset,<br
class="gmail_msg">
true,
isTailCall, true,
MemOpChains,<br
class="gmail_msg">
TailCallArguments,
dl);<br
class="gmail_msg">
@@ -5660,7 +5697,8
@@ SDValue
PPCTargetLowering::LowerCall_64S<br
class="gmail_msg">
}<br
class="gmail_msg">
}<br
class="gmail_msg">
<br
class="gmail_msg">
-
assert(NumBytesActuallyUsed
== ArgOffset);<br
class="gmail_msg">
+
assert((!HasParameterArea
||
NumBytesActuallyUsed
== ArgOffset)
&&<br
class="gmail_msg">
+ "mismatch
in size of parameter
area");<br
class="gmail_msg">
(void)NumBytesActuallyUsed;<br
class="gmail_msg">
<br
class="gmail_msg">
if
(!MemOpChains.empty())<br
class="gmail_msg">
<br
class="gmail_msg">
Added:
llvm/trunk/test/CodeGen/PowerPC/stacksize.ll<br
class="gmail_msg">
URL: <a
moz-do-not-send="true"
href="http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/PowerPC/stacksize.ll?rev=296771&view=auto"
rel="noreferrer"
class="m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-cremed
m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-cremed
m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637cremed
gmail_msg"
target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/PowerPC/stacksize.ll?rev=296771&view=auto</a><br
class="gmail_msg">
==============================================================================<br
class="gmail_msg">
---
llvm/trunk/test/CodeGen/PowerPC/stacksize.ll
(added)<br
class="gmail_msg">
+++
llvm/trunk/test/CodeGen/PowerPC/stacksize.ll
Thu Mar 2 11:38:59
2017<br
class="gmail_msg">
@@ -0,0 +1,86 @@<br
class="gmail_msg">
+; For ELFv2 ABI, we
can avoid allocating
the parameter area
in the stack frame
of the caller
function<br
class="gmail_msg">
+; if all the
arguments can be
passed to the callee
in registers.<br
class="gmail_msg">
+; For ELFv1 ABI, we
always need to
allocate the
parameter area.<br
class="gmail_msg">
+<br
class="gmail_msg">
+; Tests for ELFv2
ABI<br
class="gmail_msg">
+; RUN: llc
-verify-machineinstrs
-mtriple=powerpc64le-unknown-linux-gnu -target-abi elfv2 < %s |
FileCheck %s
-check-prefix=PPC64-ELFV2<br
class="gmail_msg">
+; RUN: llc
-verify-machineinstrs
-mtriple=powerpc64-unknown-linux-gnu -target-abi elfv2 < %s |
FileCheck %s
-check-prefix=PPC64-ELFV2<br
class="gmail_msg">
+<br
class="gmail_msg">
+; Tests for ELFv1
ABI<br
class="gmail_msg">
+; RUN: llc
-verify-machineinstrs
-mtriple=powerpc64le-unknown-linux-gnu -target-abi elfv1 < %s |
FileCheck %s
-check-prefix=PPC64-ELFV1<br
class="gmail_msg">
+; RUN: llc
-verify-machineinstrs
-mtriple=powerpc64-unknown-linux-gnu -target-abi elfv1 < %s |
FileCheck %s
-check-prefix=PPC64-ELFV1<br
class="gmail_msg">
+<br
class="gmail_msg">
+; If the callee has
at most eight
integer args,
parameter area can
be ommited for ELFv2
ABI.<br
class="gmail_msg">
+<br
class="gmail_msg">
+;
PPC64-ELFV2-LABEL:
WithoutParamArea1:<br
class="gmail_msg">
+; PPC64-ELFV2-NOT:
stw {{[0-9]+}},
-{{[0-9]+}}(1)<br
class="gmail_msg">
+; PPC64-ELFV2: stdu
1, -32(1)<br
class="gmail_msg">
+; PPC64-ELFV2: addi
1, 1, 32<br
class="gmail_msg">
+; PPC64-ELFV2-NOT:
lwz {{[0-9]+}},
-{{[0-9]+}}(1)<br
class="gmail_msg">
+;
PPC64-ELFV1-LABEL:
WithoutParamArea1:<br
class="gmail_msg">
+; PPC64-ELFV1-NOT:
stw {{[0-9]+}},
-{{[0-9]+}}(1)<br
class="gmail_msg">
+; PPC64-ELFV1: stdu
1, -112(1)<br
class="gmail_msg">
+; PPC64-ELFV1: addi
1, 1, 112<br
class="gmail_msg">
+; PPC64-ELFV1-NOT:
lwz {{[0-9]+}},
-{{[0-9]+}}(1)<br
class="gmail_msg">
+define signext i32
@WithoutParamArea1(i32 signext %a) local_unnamed_addr #0 {<br
class="gmail_msg">
+entry:<br
class="gmail_msg">
+ %call = tail call
signext i32
@onearg(i32 signext
%a) #2<br
class="gmail_msg">
+ ret i32 %call<br
class="gmail_msg">
+}<br
class="gmail_msg">
+<br
class="gmail_msg">
+;
PPC64-ELFV2-LABEL:
WithoutParamArea2:<br
class="gmail_msg">
+; PPC64-ELFV2-NOT:
stw {{[0-9]+}},
-{{[0-9]+}}(1)<br
class="gmail_msg">
+; PPC64-ELFV2: stdu
1, -32(1)<br
class="gmail_msg">
+; PPC64-ELFV2: addi
1, 1, 32<br
class="gmail_msg">
+; PPC64-ELFV2-NOT:
lwz {{[0-9]+}},
-{{[0-9]+}}(1)<br
class="gmail_msg">
+;
PPC64-ELFV1-LABEL:
WithoutParamArea2:<br
class="gmail_msg">
+; PPC64-ELFV1-NOT:
stw {{[0-9]+}},
-{{[0-9]+}}(1)<br
class="gmail_msg">
+; PPC64-ELFV1: stdu
1, -112(1)<br
class="gmail_msg">
+; PPC64-ELFV1: addi
1, 1, 112<br
class="gmail_msg">
+; PPC64-ELFV1-NOT:
lwz {{[0-9]+}},
-{{[0-9]+}}(1)<br
class="gmail_msg">
+define signext i32
@WithoutParamArea2(i32 signext %a) local_unnamed_addr #0 {<br
class="gmail_msg">
+entry:<br
class="gmail_msg">
+ %call = tail call
signext i32
@eightargs(i32
signext %a, i32
signext %a, i32
signext %a, i32
signext %a, i32
signext %a, i32
signext %a, i32
signext %a, i32
signext %a) #2<br
class="gmail_msg">
+ ret i32 %call<br
class="gmail_msg">
+}<br
class="gmail_msg">
+<br
class="gmail_msg">
+; If the callee has
more than eight
integer args or
variable number of
args,<br
class="gmail_msg">
+; parameter area
cannot be ommited
even for ELFv2 ABI<br
class="gmail_msg">
+<br
class="gmail_msg">
+;
PPC64-ELFV2-LABEL:
WithParamArea1:<br
class="gmail_msg">
+; PPC64-ELFV2-NOT:
stw {{[0-9]+}},
-{{[0-9]+}}(1)<br
class="gmail_msg">
+; PPC64-ELFV2: stdu
1, -96(1)<br
class="gmail_msg">
+; PPC64-ELFV2: addi
1, 1, 96<br
class="gmail_msg">
+; PPC64-ELFV2-NOT:
lwz {{[0-9]+}},
-{{[0-9]+}}(1)<br
class="gmail_msg">
+;
PPC64-ELFV1-LABEL:
WithParamArea1:<br
class="gmail_msg">
+; PPC64-ELFV1-NOT:
stw {{[0-9]+}},
-{{[0-9]+}}(1)<br
class="gmail_msg">
+; PPC64-ELFV1: stdu
1, -112(1)<br
class="gmail_msg">
+; PPC64-ELFV1: addi
1, 1, 112<br
class="gmail_msg">
+; PPC64-ELFV1-NOT:
lwz {{[0-9]+}},
-{{[0-9]+}}(1)<br
class="gmail_msg">
+define signext i32
@WithParamArea1(i32
signext %a)
local_unnamed_addr
#0 {<br
class="gmail_msg">
+entry:<br
class="gmail_msg">
+ %call = tail call
signext i32 (i32,
...) @varargs(i32
signext %a, i32
signext %a) #2<br
class="gmail_msg">
+ ret i32 %call<br
class="gmail_msg">
+}<br
class="gmail_msg">
+<br
class="gmail_msg">
+;
PPC64-ELFV2-LABEL:
WithParamArea2:<br
class="gmail_msg">
+; PPC64-ELFV2-NOT:
stw {{[0-9]+}},
-{{[0-9]+}}(1)<br
class="gmail_msg">
+; PPC64-ELFV2: stdu
1, -112(1)<br
class="gmail_msg">
+; PPC64-ELFV2: addi
1, 1, 112<br
class="gmail_msg">
+; PPC64-ELFV2-NOT:
lwz {{[0-9]+}},
-{{[0-9]+}}(1)<br
class="gmail_msg">
+;
PPC64-ELFV1-LABEL:
WithParamArea2:<br
class="gmail_msg">
+; PPC64-ELFV1-NOT:
stw {{[0-9]+}},
-{{[0-9]+}}(1)<br
class="gmail_msg">
+; PPC64-ELFV1: stdu
1, -128(1)<br
class="gmail_msg">
+; PPC64-ELFV1: addi
1, 1, 128<br
class="gmail_msg">
+; PPC64-ELFV1-NOT:
lwz {{[0-9]+}},
-{{[0-9]+}}(1)<br
class="gmail_msg">
+define signext i32
@WithParamArea2(i32
signext %a)
local_unnamed_addr
#0 {<br
class="gmail_msg">
+entry:<br
class="gmail_msg">
+ %call = tail call
signext i32
@nineargs(i32
signext %a, i32
signext %a, i32
signext %a, i32
signext %a, i32
signext %a, i32
signext %a, i32
signext %a, i32
signext %a, i32
signext %a) #2<br
class="gmail_msg">
+ ret i32 %call<br
class="gmail_msg">
+}<br
class="gmail_msg">
+<br
class="gmail_msg">
+declare signext i32
@onearg(i32 signext)
local_unnamed_addr
#1<br
class="gmail_msg">
+declare signext i32
@eightargs(i32
signext, i32
signext, i32
signext, i32
signext, i32
signext, i32
signext, i32
signext, i32
signext)
local_unnamed_addr
#1<br
class="gmail_msg">
+declare signext i32
@nineargs(i32
signext, i32
signext, i32
signext, i32
signext, i32
signext, i32
signext, i32
signext, i32
signext, i32
signext)
local_unnamed_addr
#1<br
class="gmail_msg">
+declare signext i32
@varargs(i32
signext, ...)
local_unnamed_addr
#1<br
class="gmail_msg">
+<br
class="gmail_msg">
<br
class="gmail_msg">
<br
class="gmail_msg">
_______________________________________________<br class="gmail_msg">
llvm-commits mailing
list<br
class="gmail_msg">
<a
moz-do-not-send="true"
href="mailto:llvm-commits@lists.llvm.org"
class="m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-cremed
m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-cremed
m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637cremed
gmail_msg"
target="_blank">llvm-commits@lists.llvm.org</a><br
class="gmail_msg">
<a
moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits"
rel="noreferrer"
class="m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-cremed
m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-cremed
m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637cremed
gmail_msg"
target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br
class="gmail_msg">
</blockquote>
</div>
<br class="gmail_msg">
</div>
</div>
</div>
</blockquote>
</div>
<br class="gmail_msg">
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="gmail_msg">
</div>
_______________________________________________<br
class="gmail_msg">
llvm-commits mailing list<br class="gmail_msg">
<a moz-do-not-send="true"
href="mailto:llvm-commits@lists.llvm.org"
class="gmail_msg" target="_blank">llvm-commits@lists.llvm.org</a><br
class="gmail_msg">
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits"
rel="noreferrer" class="gmail_msg"
target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br
class="gmail_msg">
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
llvm-commits mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>