[LLVMdev] byval in a world without pointee types

[David Blaikie]

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>