byval in a world without pointee types

[David Blaikie]

On Thu, Feb 19, 2015 at 11:17 AM, Nick Lewycky <nicholas at mxc.ca> wrote:

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

Ah, fair. Actually it looks like we might already be using it...

$ cat byval.cpp
struct foo {
  int x[42] __attribute__((aligned(16)));
};

void func(foo) {
}
$ clang++-tot byval.cpp -emit-llvm -S -o - | grep define
define void @_Z4func3foo(%struct.foo* byval align 16) #0 {

(& without the aligned attribute, it has "align 8")

So maybe we're emitting it from clang & currently ignoring it in favor of
using the type's own alignment, and I should fix that first so we just rely
on the pointer's alignment? I'll need to poke around with it & see if I can
understand if that's what's happening, first.

Ugh - PPCISelLowering::getByValTypeAlignment does all sorts of stuff with
the type to decide on the alignment - I guess that'll need to be pushed up
into clang maybe?

- David


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