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

[Eddy B. via llvm-dev]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160124/92348a7b/attachment.html>