<div dir="ltr"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Wed, Mar 8, 2017, 03:18 Hal Finkel <<a href="mailto:hfinkel@anl.gov" class="gmail_msg" target="_blank">hfinkel@anl.gov</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" id="m_-1008270039840574025gmail_block_quote0"><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
<p class="gmail_msg"><br class="gmail_msg">
</p>
<div class="m_-1008270039840574025m_-5930978924227032261moz-cite-prefix gmail_msg">On 03/07/2017 08:43 PM, Tim Shen via
llvm-commits wrote:<br class="gmail_msg">
</div>
<blockquote type="cite" class="gmail_msg">
<div dir="ltr" class="gmail_msg">
<div class="gmail_quote gmail_msg">
<div dir="ltr" class="gmail_msg">On Tue, Mar 7, 2017 at 6:21 PM Tim Shen <<a 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">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 class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">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 class="gmail_msg"></div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
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 class="gmail_msg"></div></blockquote></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Yes, we might be able to do that.</div><div class="gmail_msg"><br></div><div class="gmail_msg">A normal usage of casting a function pointer is type erasure. In that case, we can suggest the user to cast to void* if possible (*). For function-pointer to function-pointer cast, issue a warning.</div><div class="gmail_msg"><br></div><div class="gmail_msg">CC Richard.</div><div class="gmail_msg"><br></div><div class="gmail_msg">* Casting a function pointer from and to data pointer is implementation defined: <a href="http://en.cppreference.com/w/cpp/language/reinterpret_cast">http://en.cppreference.com/w/cpp/language/reinterpret_cast</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" id="m_-1008270039840574025gmail_block_quote1"><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
<br class="gmail_msg">
-Hal</div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg"><br class="gmail_msg">
<br class="gmail_msg">
<blockquote type="cite" class="gmail_msg">
<div dir="ltr" class="gmail_msg">
<div class="gmail_quote gmail_msg">
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">For this failure it's not the patch's fault. I'll revert
the revert and test it again.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">Sorry for the disturbance!</div>
<div class="gmail_msg"> </div>
<blockquote class="gmail_quote gmail_msg" 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 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 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 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 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_-1008270039840574025m_-5930978924227032261m_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 href="mailto:djasper@google.com" class="m_-1008270039840574025m_-5930978924227032261m_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_-1008270039840574025m_-5930978924227032261m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-m_431023069260411042HOEnZb gmail_msg">
<div class="m_-1008270039840574025m_-5930978924227032261m_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 href="mailto:llvm-commits@lists.llvm.org" class="m_-1008270039840574025m_-5930978924227032261m_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 href="http://llvm.org/viewvc/llvm-project?rev=296771&view=rev" rel="noreferrer" class="m_-1008270039840574025m_-5930978924227032261m_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 href="https://reviews.llvm.org/D29881" rel="noreferrer" class="m_-1008270039840574025m_-5930978924227032261m_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 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_-1008270039840574025m_-5930978924227032261m_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 href="http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/PowerPC/stacksize.ll?rev=296771&view=auto" rel="noreferrer" class="m_-1008270039840574025m_-5930978924227032261m_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 href="mailto:llvm-commits@lists.llvm.org" class="m_-1008270039840574025m_-5930978924227032261m_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 href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" class="m_-1008270039840574025m_-5930978924227032261m_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 href="mailto:llvm-commits@lists.llvm.org" class="gmail_msg" target="_blank">llvm-commits@lists.llvm.org</a><br class="gmail_msg">
<a 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 class="gmail_msg">
<fieldset class="m_-1008270039840574025m_-5930978924227032261mimeAttachmentHeader gmail_msg"></fieldset>
<br class="gmail_msg">
<pre class="gmail_msg">_______________________________________________
llvm-commits mailing list
<a class="m_-1008270039840574025m_-5930978924227032261moz-txt-link-abbreviated gmail_msg" href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>
<a class="m_-1008270039840574025m_-5930978924227032261moz-txt-link-freetext gmail_msg" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a>
</pre>
</blockquote>
<br class="gmail_msg">
</div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg"><pre class="m_-1008270039840574025m_-5930978924227032261moz-signature gmail_msg" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</div></blockquote></div></div>