byval in a world without pointee types

[Nick Lewycky]

David Blaikie wrote:
>
>
> On Thu, Feb 19, 2015 at 8:31 AM, Rafael Espíndola
> <rafael.espindola at gmail.com <mailto: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 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

We have a standalone attribute for pointer alignment, we can just use that.

>
>
>     Cheers,
>     Rafael
>
>
>
>     On 15 February 2015 at 13:59, David Blaikie <dblaikie at gmail.com
>     <mailto: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 <mailto:llvm-commits at cs.uiuc.edu>
>      > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>      >
>
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits