<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 24, 2016 at 12:52 PM, Eddy B. via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2016-01-24 20:25 GMT+02:00 Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<br>
On 01/19/2016 02:47 PM, Eddy B. via llvm-dev wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
In the past months, several options have been presented for making byval<br>
(and similar attributes, such as inalloca or sret) work with opaque pointers.<br>
<br>
The main two I've seen were byval(T) and byval(N) where N is the size of T.<br>
<br>
They both have their upsides and downsides, for example: byval(T) would be<br>
a type-parametric attribute, which, AFAIK, does not already exist and may<br>
complicate the attribute system significantly, while byval(N) would be hard<br>
to introduce in tests as computing N from T requires LLVM's DataLayout.<br>
<br>
Also, this would have to be done for inalloca and sret as well - sret only<br>
needs it when targeting SPARC, although still generally useful in analysis.<br>
<br>
To sidestep some of the concerns and allow a smooth transition towards a<br>
byval that works with opaque pointers, I've come up with a new approach:<br>
<br>
Reuse dereferenceable(S) and align A for the size and alignment of byval.<br>
<br>
That is, a byval dereferenceable(S) align A argument is guaranteed to have<br>
S bytes available to read from, *and only S*, aligned to a multiple of A.<br>
Reading past that size is UB, as LLVM will not copy more than S bytes.<br>
</blockquote></span>
Just to make sure I understand, you are *not* planning on changing the semantics of the existing attributes right?  The current semantics for "dereferenceable(N)" are "N bytes are known to be dereferenceable, more bytes might be".  What worried my in your wording was the UB comment.  It is not currently UB to have a read beyond the *known* dereferenceable bytes.  This is important to me and I would be very hesitant to change it.</blockquote></span><div>The semantics I described were for byval+dereferenceable(N), not dereferenceable(N) alone,</div><div>i.e. LLVM will only guarantee exactly N bytes will be copied, no less, no more.</div><div><br></div><div>Although with mjacob prototyping byval(T) so quickly, I do feel that my work is obsoleted.</div></div></div></div></blockquote><div><br>Even with the prototype (which I haven't looked at in detail) I think this thread (& your prototype) is still valuable & would like to continue it/hear from others (especially those I cc'd earlier) about preferences/ideas/tradeoffs in the design of this piece.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>