[llvm-dev] [RFC] A proposal for byval in a world with opaque pointers

[David Blaikie via llvm-dev]

On Sun, Jan 24, 2016 at 12:52 PM, Eddy B. via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> 2016-01-24 20:25 GMT+02:00 Philip Reames <listmail at philipreames.com>:
>
>>
>>
>> On 01/19/2016 02:47 PM, Eddy B. via llvm-dev wrote:
>>
>>> Hi,
>>>
>>> In the past months, several options have been presented for making byval
>>> (and similar attributes, such as inalloca or sret) work with opaque
>>> pointers.
>>>
>>> The main two I've seen were byval(T) and byval(N) where N is the size of
>>> T.
>>>
>>> They both have their upsides and downsides, for example: byval(T) would
>>> be
>>> a type-parametric attribute, which, AFAIK, does not already exist and may
>>> complicate the attribute system significantly, while byval(N) would be
>>> hard
>>> to introduce in tests as computing N from T requires LLVM's DataLayout.
>>>
>>> Also, this would have to be done for inalloca and sret as well - sret
>>> only
>>> needs it when targeting SPARC, although still generally useful in
>>> analysis.
>>>
>>> To sidestep some of the concerns and allow a smooth transition towards a
>>> byval that works with opaque pointers, I've come up with a new approach:
>>>
>>> Reuse dereferenceable(S) and align A for the size and alignment of byval.
>>>
>>> That is, a byval dereferenceable(S) align A argument is guaranteed to
>>> have
>>> S bytes available to read from, *and only S*, aligned to a multiple of A.
>>> Reading past that size is UB, as LLVM will not copy more than S bytes.
>>>
>> 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.
>
> The semantics I described were for byval+dereferenceable(N), not
> dereferenceable(N) alone,
> i.e. LLVM will only guarantee exactly N bytes will be copied, no less, no
> more.
>
> Although with mjacob prototyping byval(T) so quickly, I do feel that my
> work is obsoleted.
>

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.


>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160124/638e1401/attachment-0001.html>