llvm dev - Mar 2015 - [LLVMdev] byval in a world without pointee types

Moving this to llvm-dev where I should've sent it in the first place (&
+Chandler, because we discussed this offline a bit)

On Thu, Feb 19, 2015 at 11:32 AM, Reid Kleckner <rnk at google.com> wrote:
> On Thu, Feb 19, 2015 at 10:57 AM, David Blaikie <dblaikie at
gmail.com>
> wrote:
>
>>
>>
>> On Thu, Feb 19, 2015 at 8:31 AM, Rafael Espíndola <
>> rafael.espindola at gmail.com> wrote:
>>
>>> Long term I would love to remove byval and sret. With inalloca the
>>> outgoing frame is explicit a the IR and we just have loads and
stores.
>>>
>>> A short term idea would be to add just the size to the byval. That
>>> should be sufficient, no?
>>
>>
> I like this idea!
>
So do I.

Chandler had some other thoughts that I'll attempt to express here:

* When you get right down to it, byval seems rather similar to alloca and
global variables (they're all just some number of bytes with a required
alignment)
* If we're changing byval should we change alloca and/or globals, too?
(I'm
a bit more of a pragmatist in this domain, and I'm not /too/ fussed about
changing the one that's tricky (byval) and leaving the other two)
* We could just change their IR APIs to take a type but lower to
bytes+alignment - textual/bitcode would be all size+alignment, but the C++
APIs for creating these constructs would still allow the user to pass in a
type as a convenience. (Chandler suggested possibly keeping the textual IR
allowing types to be specified - but the bitcode to be size+alignment, and
deserializing that into a [i8 x N], but just supporting the C++ API seems
sufficient to me but I hadn't thought of that in my conversation with him)

This does reflect part of the point of typeless pointers: that memory isn't
typed, it's just bytes (and alignment). Globals, allocas, and byvals are
all just that.

Does any of this sound important/reasonable?

>
>
>> I was going to agree - but poking around, it looks like we need
alignment
>> too, at least (not sure if we need other things beyond size &
alignment,
>> nothing springs to mind but I don't know much about this stuff) -
>>
TargetLoweringBase::getByValTypeAlignment/DataLayout::getABITypeAlignment
>>
>
> Nope, we don't, we have an align attribute. =D
>
Yep, seemed the align attribute wasn't always set in the frontend (&
there's a comment in the backend where getByValTypeAlignment is called
saying essentially "this is a fallback, it's not always correct,
frontends
should emit an align attribute if this isn't the behavior they want").
But
PPC32 is the only one using a complex implementation of this function,
everyone else, if they use it at all (which I think might be NVPTX and some
others) just uses the default, which is the llvm::Type's alignment.

I'm working on moving this sort of thing to clang. The auto-upgrade might
be a bit annoying, though (as we'll have to keep a bunch of that fallback
logic around, but at least it'll just be in the auto-upgrader?)

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150309/d7fb4d52/attachment.html>

If we're keeping types on GEP, then IMO we should keep them on allocas and
globals. It keeps the IR human readable.

We're pretty close to mandatory data layout, so computing the size and
alignment of these things when they aren't explicitly specified should be
easy.

On Mon, Mar 9, 2015 at 9:57 AM, David Blaikie <dblaikie at gmail.com>
wrote:
> Moving this to llvm-dev where I should've sent it in the first place
(&
> +Chandler, because we discussed this offline a bit)
>
> On Thu, Feb 19, 2015 at 11:32 AM, Reid Kleckner <rnk at google.com>
wrote:
>
>> On Thu, Feb 19, 2015 at 10:57 AM, David Blaikie <dblaikie at
gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, Feb 19, 2015 at 8:31 AM, Rafael Espíndola <
>>> rafael.espindola at gmail.com> wrote:
>>>
>>>> Long term I would love to remove byval and sret. With inalloca
the
>>>> outgoing frame is explicit a the IR and we just have loads and
stores.
>>>>
>>>> A short term idea would be to add just the size to the byval.
That
>>>> should be sufficient, no?
>>>
>>>
>> I like this idea!
>>
>
> So do I.
>
> Chandler had some other thoughts that I'll attempt to express here:
>
> * When you get right down to it, byval seems rather similar to alloca and
> global variables (they're all just some number of bytes with a required
> alignment)
> * If we're changing byval should we change alloca and/or globals, too?
> (I'm a bit more of a pragmatist in this domain, and I'm not /too/
fussed
> about changing the one that's tricky (byval) and leaving the other two)
> * We could just change their IR APIs to take a type but lower to
> bytes+alignment - textual/bitcode would be all size+alignment, but the C++
> APIs for creating these constructs would still allow the user to pass in a
> type as a convenience. (Chandler suggested possibly keeping the textual IR
> allowing types to be specified - but the bitcode to be size+alignment, and
> deserializing that into a [i8 x N], but just supporting the C++ API seems
> sufficient to me but I hadn't thought of that in my conversation with
him)
>
> This does reflect part of the point of typeless pointers: that memory
> isn't typed, it's just bytes (and alignment). Globals, allocas, and
byvals
> are all just that.
>
> Does any of this sound important/reasonable?
>
>
>>
>>
>>> I was going to agree - but poking around, it looks like we need
>>> alignment too, at least (not sure if we need other things beyond
size &
>>> alignment, nothing springs to mind but I don't know much about
this stuff)
>>> -
TargetLoweringBase::getByValTypeAlignment/DataLayout::getABITypeAlignment
>>>
>>
>> Nope, we don't, we have an align attribute. =D
>>
>
> Yep, seemed the align attribute wasn't always set in the frontend
(&
> there's a comment in the backend where getByValTypeAlignment is called
> saying essentially "this is a fallback, it's not always correct,
frontends
> should emit an align attribute if this isn't the behavior they
want"). But
> PPC32 is the only one using a complex implementation of this function,
> everyone else, if they use it at all (which I think might be NVPTX and some
> others) just uses the default, which is the llvm::Type's alignment.
>
> I'm working on moving this sort of thing to clang. The auto-upgrade
might
> be a bit annoying, though (as we'll have to keep a bunch of that
fallback
> logic around, but at least it'll just be in the auto-upgrader?)
>
> - David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150309/b98290b3/attachment.html>

On Mon, Mar 9, 2015 at 12:38 PM, Reid Kleckner <rnk at google.com> wrote:
> If we're keeping types on GEP,
>
You mean rather than just dropping gep entirely & doing manual pointer
arithmetic? (& moving inbounds to an attribute on pointer addition, I
guess?)

> then IMO we should keep them on allocas and globals. It keeps the IR human
> readable.
>
& what of byval, then? Do you agree with Chandler's argument from
analogy
between byval, alloca, and globals?

(oh, and I should look at inalloca a bit too - it looks like it uses
the getByValTypeAlignment
too... )

- David

>
> We're pretty close to mandatory data layout, so computing the size and
> alignment of these things when they aren't explicitly specified should
be
> easy.
>
> On Mon, Mar 9, 2015 at 9:57 AM, David Blaikie <dblaikie at gmail.com>
wrote:
>
>> Moving this to llvm-dev where I should've sent it in the first
place (&
>> +Chandler, because we discussed this offline a bit)
>>
>> On Thu, Feb 19, 2015 at 11:32 AM, Reid Kleckner <rnk at
google.com> wrote:
>>
>>> On Thu, Feb 19, 2015 at 10:57 AM, David Blaikie <dblaikie at
gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Feb 19, 2015 at 8:31 AM, Rafael Espíndola <
>>>> rafael.espindola at gmail.com> wrote:
>>>>
>>>>> Long term I would love to remove byval and sret. With
inalloca the
>>>>> outgoing frame is explicit a the IR and we just have loads
and stores.
>>>>>
>>>>> A short term idea would be to add just the size to the
byval. That
>>>>> should be sufficient, no?
>>>>
>>>>
>>> I like this idea!
>>>
>>
>> So do I.
>>
>> Chandler had some other thoughts that I'll attempt to express here:
>>
>> * When you get right down to it, byval seems rather similar to alloca
and
>> global variables (they're all just some number of bytes with a
required
>> alignment)
>> * If we're changing byval should we change alloca and/or globals,
too?
>> (I'm a bit more of a pragmatist in this domain, and I'm not
/too/ fussed
>> about changing the one that's tricky (byval) and leaving the other
two)
>> * We could just change their IR APIs to take a type but lower to
>> bytes+alignment - textual/bitcode would be all size+alignment, but the
C++
>> APIs for creating these constructs would still allow the user to pass
in a
>> type as a convenience. (Chandler suggested possibly keeping the textual
IR
>> allowing types to be specified - but the bitcode to be size+alignment,
and
>> deserializing that into a [i8 x N], but just supporting the C++ API
seems
>> sufficient to me but I hadn't thought of that in my conversation
with him)
>>
>> This does reflect part of the point of typeless pointers: that memory
>> isn't typed, it's just bytes (and alignment). Globals, allocas,
and byvals
>> are all just that.
>>
>> Does any of this sound important/reasonable?
>>
>>
>>>
>>>
>>>> I was going to agree - but poking around, it looks like we need
>>>> alignment too, at least (not sure if we need other things
beyond size &
>>>> alignment, nothing springs to mind but I don't know much
about this stuff)
>>>> -
TargetLoweringBase::getByValTypeAlignment/DataLayout::getABITypeAlignment
>>>>
>>>
>>> Nope, we don't, we have an align attribute. =D
>>>
>>
>> Yep, seemed the align attribute wasn't always set in the frontend
(&
>> there's a comment in the backend where getByValTypeAlignment is
called
>> saying essentially "this is a fallback, it's not always
correct, frontends
>> should emit an align attribute if this isn't the behavior they
want"). But
>> PPC32 is the only one using a complex implementation of this function,
>> everyone else, if they use it at all (which I think might be NVPTX and
some
>> others) just uses the default, which is the llvm::Type's alignment.
>>
>> I'm working on moving this sort of thing to clang. The auto-upgrade
might
>> be a bit annoying, though (as we'll have to keep a bunch of that
fallback
>> logic around, but at least it'll just be in the auto-upgrader?)
>>
>> - David
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150309/871cfa55/attachment.html>