byval in a world without pointee types

[David Blaikie]

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


>
> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150219/66465e0b/attachment.html>