byval in a world without pointee types

[Rafael Espíndola]

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?

Cheers,
Rafael



On 15 February 2015 at 13:59, David Blaikie <dblaikie at gmail.com> wrote:
> This was brought up on IRC the other day & I've been tossing it around a
> bit.
>
> Roughly, I think it makes sense to move the pointee type to the byval
> attribute:
>
>   %struct.foo* byval %x
> to
>   ptr byval(%struct.foo) %x
>
> but looking at the code I'm not quite sure how to go about it. There
> currently appear to be enum attributes (anything well typed in the IR,
> essentially?), integer attributes (well typed enum attributes with an
> integer parameter (align 4, dereferenceable 8, etc)) and string attributes
> (untyped in the IR - for target specific features).
>
> The quirk of interest is that it seems integer attributes can all be
> multiply specified (align 4 align 8 and dereferenceable 8 dereferenceable 3)
> - I'm not sure what this actually means (do we take the max? I assume we
> do), but when I reached the Attribute sorting code it looks like it treats
> these as distinct attributes at least and I wasn't sure if/how to cope with
> this for a type attribute - should they be ordered (are Types orderable?)?
> or should we be doing some kind of deduplication earlier on and say that
> there's only one byval attribute (if I'm adding that machinery, should we
> apply it to align, dereferencable, etc - I guess they get coalesced
> /somewhere/ at least).
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>