<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 03/08/2017 01:29 PM, Tim Shen wrote:<br>
</div>
<blockquote
cite="mid:CAG4ZjNnD6S6_JatOCBhW-eCQvvLQfQLexyi=MvTg_mbVXqYsfw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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 moz-do-not-send="true"
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 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">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>
</blockquote>
<br>
I was specifically thinking about warning on a cast between a
var-args function and a non-var-args function. Would that have
produced a warning in the code that you have? We could do a similar
thing for other kinds of basic parameter incompatibilities (i.e. a
function that takes an int to one that takes a float). Some of this
we might already do.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CAG4ZjNnD6S6_JatOCBhW-eCQvvLQfQLexyi=MvTg_mbVXqYsfw@mail.gmail.com"
type="cite">
<div dir="ltr">
<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
moz-do-not-send="true"
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
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_-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
moz-do-not-send="true" href="mailto:djasper@google.com"
class="m_-1008270039840574025m_-5930978924227032261m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-cremedm_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
moz-do-not-send="true" href="mailto:llvm-commits@lists.llvm.org"
class="m_-1008270039840574025m_-5930978924227032261m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-cremedm_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_-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
moz-do-not-send="true" 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
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_-1008270039840574025m_-5930978924227032261m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-cremedm_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_-1008270039840574025m_-5930978924227032261m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-cremedm_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_-1008270039840574025m_-5930978924227032261m_5105410782478699609m_4965356181045716379m_-5054895815689520580m_-3006038768846699405m_1579643965024872637gmail-cremedm_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_-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 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 class="gmail_msg">
<fieldset
class="m_-1008270039840574025m_-5930978924227032261mimeAttachmentHeader
gmail_msg"></fieldset>
<br class="gmail_msg">
<pre class="gmail_msg">_______________________________________________
llvm-commits mailing list
<a moz-do-not-send="true" 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 moz-do-not-send="true" 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>
</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>