[LLVMdev] byval in a world without pointee types

[David Blaikie]

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>