<div dir="ltr">In an internal function, I found the a very early instruction modifies the first parameter (r3):<br> ld r3,-31576(r2)<div><br>which immediately clobbers r3. Succeeding operations on r3 causes a crash.<br><div><br></div><div>My guess would be this function assumes the parameters are on the stack, while the caller doesn't assume so.</div><div><br></div><div>Still investigating.</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Mar 7, 2017 at 1:59 AM Nemanja Ivanovic via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</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"><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_-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_-3006038768846699405m_1579643965024872637gmail-cremed m_-3006038768846699405m_1579643965024872637gmail-cremed m_-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_-3006038768846699405m_1579643965024872637gmail-m_431023069260411042HOEnZb gmail_msg"><div class="m_-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_-3006038768846699405m_1579643965024872637gmail-cremed m_-3006038768846699405m_1579643965024872637gmail-cremed m_-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_-3006038768846699405m_1579643965024872637gmail-cremed m_-3006038768846699405m_1579643965024872637gmail-cremed m_-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_-3006038768846699405m_1579643965024872637gmail-cremed m_-3006038768846699405m_1579643965024872637gmail-cremed m_-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_-3006038768846699405m_1579643965024872637gmail-cremed m_-3006038768846699405m_1579643965024872637gmail-cremed m_-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_-3006038768846699405m_1579643965024872637gmail-cremed m_-3006038768846699405m_1579643965024872637gmail-cremed m_-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_-3006038768846699405m_1579643965024872637gmail-cremed m_-3006038768846699405m_1579643965024872637gmail-cremed m_-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_-3006038768846699405m_1579643965024872637gmail-cremed m_-3006038768846699405m_1579643965024872637gmail-cremed m_-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>