[LLVMdev] byval in a world without pointee types

David Blaikie dblaikie at gmail.com
Mon Mar 9 09:57:05 PDT 2015

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
* 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>

More information about the llvm-dev mailing list