<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/29/12 1:07 PM, Bob Wilson wrote:<br>
</div>
<blockquote
cite="mid:314D67A0-DC0B-47D4-88D8-0FB8BE370A8D@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On Oct 28, 2012, at 12:48 PM, Chris Lattner <<a
moz-do-not-send="true" href="mailto:clattner@apple.com">clattner@apple.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space; "><br>
<div>
<div>On Oct 26, 2012, at 7:27 AM, Duncan Sands <<a
moz-do-not-send="true" href="mailto:baldrick@free.fr">baldrick@free.fr</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<blockquote type="cite" style="font-family: Helvetica;
font-size: medium; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: 2; text-align:
-webkit-auto; text-indent: 0px; text-transform: none;
white-space: normal; widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; ">
<blockquote type="cite">That is a strange byval
implementation. Maybe the llvm ARM backend<br>
should be changed to always pass byval on the stack?
Clang can create<br>
regular (integer, fp) arguments for the registers.<br>
</blockquote>
<br>
The current definition of the byval attribute in
LangRef says nothing about requiring passing the
argument on the stack. It just says it "should really
be passed by value". When discussing the alignment,
it does refer to a stack slot, but it isn't at all
clear that it is required to be on the stack.<br>
</blockquote>
<br style="font-family: Helvetica; font-size: medium;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-align: -webkit-auto; text-indent:
0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; ">
<span style="font-family: Helvetica; font-size: medium;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-align: -webkit-auto; text-indent:
0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; display: inline
!important; float: none; ">it needs to be addressable.
The "byval" parameter is a pointer, and that</span><br
style="font-family: Helvetica; font-size: medium;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-align: -webkit-auto; text-indent:
0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; ">
<span style="font-family: Helvetica; font-size: medium;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-align: -webkit-auto; text-indent:
0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; display: inline
!important; float: none; ">pointer can be passed to
any old routine as an ordinary pointer, and they</span><br
style="font-family: Helvetica; font-size: medium;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-align: -webkit-auto; text-indent:
0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; ">
<span style="font-family: Helvetica; font-size: medium;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-align: -webkit-auto; text-indent:
0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; display: inline
!important; float: none; ">may read or write the
memory it points to. So while you could pass in</span><br
style="font-family: Helvetica; font-size: medium;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-align: -webkit-auto; text-indent:
0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; ">
</blockquote>
<br>
</div>
<div>Right, this is my gripe with "byval". It makes a lot
of sense for large things that need to be passed on the
stack, but very little sense for small things that need to
be passed that way. Clang on i386 suffers a number of
code quality issues because it can't express this "I don't
need it to be addressable, but I do need it passed on the
stack" concept. An "onstack" attribute seems the perfect
analog to "inreg" to fix this. That is, if anyone still
cares about i386 :-)</div>
</div>
</blockquote>
<br>
</div>
<div>I agree that an "onstack" attribute would make sense.</div>
<div><br>
</div>
<div>After we have that, we should also clarify the behavior of
"byval". It currently is interpreted differently for different
targets. Duncan is right about byval arguments needing to be
addressable, but some targets pass byval arguments in registers
(or at least partially in registers) and then store the values
to the stack. A separate "onstack" attribute might allow us to
come up with a more consistent definition of "byval".</div>
</blockquote>
<br>
So, if I understand what you're proposing, "onstack" means that
something should be passed on the stack, and "byval" means that the
compiler inserts an invisible copy of the data when performing the
function call. That would then mean that something that is both
"byval" and "onstack" means that something has been copied and is
located on the stack. Is this correct?<br>
<br>
Tools like SAFECode (and maybe ASan) rely on being able to identify
memory allocations at the LLVM IR level; this includes things like
byval arguments where the only information about the memory
allocation is the byval argument itself. For example, SAFECode
instruments functions with byval arguments to record the size and
location of the byval argument.<br>
<br>
If there's no reliable way to tell if the code generator added a
memory allocation and, if so, where the memory is and what size it
is, then parts of SAFECode would have to work at the MachineInstr
level and might have to be platform dependent. We'd like to avoid
that if possible.<br>
:)<br>
<br>
-- John T.<br>
<br>
P.S. We still care about i386, but that's mainly because one of our
funding agencies still does (they evaluate SAFECode on i386).<br>
<br>
</body>
</html>