<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 19, 2015 at 11:17 AM, Nick Lewycky <span dir="ltr"><<a href="mailto:nicholas@mxc.ca" target="_blank">nicholas@mxc.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">David Blaikie wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<br>
<br>
On Thu, Feb 19, 2015 at 8:31 AM, Rafael Espíndola<br></span><span class="">
<<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a> <mailto:<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@<u></u>gmail.com</a>>> wrote:<br>
<br>
Long term I would love to remove byval and sret. With inalloca the<br>
outgoing frame is explicit a the IR and we just have loads and stores.<br>
<br>
A short term idea would be to add just the size to the byval. That<br>
should be sufficient, no?<br>
<br>
<br>
I was going to agree - but poking around, it looks like we need<br>
alignment too, at least (not sure if we need other things beyond size &<br>
alignment, nothing springs to mind but I don't know much about this<br>
stuff) -<br>
TargetLoweringBase::<u></u>getByValTypeAlignment/<u></u>DataLayout::<u></u>getABITypeAlignment<br>
</span></blockquote>
<br>
We have a standalone attribute for pointer alignment, we can just use that.<br></blockquote><div><br>Ah, fair. Actually it looks like we might already be using it... <br><br><div>$ cat byval.cpp</div><div>struct foo {</div><div> int x[42] __attribute__((aligned(16)));</div><div>};</div><div><br></div><div>void func(foo) {</div><div>}</div><div>$ clang++-tot byval.cpp -emit-llvm -S -o - | grep define</div><div>define void @_Z4func3foo(%struct.foo* byval align 16) #0 {<br><br>(& without the aligned attribute, it has "align 8")<br><br>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.<br><br>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?<br><br>- David<br><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<br>
<br>
Cheers,<br>
Rafael<br>
<br>
<br>
<br>
On 15 February 2015 at 13:59, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a><br></span><div><div class="h5">
<mailto:<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>>> wrote:<br>
> This was brought up on IRC the other day & I've been tossing it<br>
around a<br>
> bit.<br>
><br>
> Roughly, I think it makes sense to move the pointee type to the byval<br>
> attribute:<br>
><br>
> %struct.foo* byval %x<br>
> to<br>
> ptr byval(%struct.foo) %x<br>
><br>
> but looking at the code I'm not quite sure how to go about it. There<br>
> currently appear to be enum attributes (anything well typed in<br>
the IR,<br>
> essentially?), integer attributes (well typed enum attributes with an<br>
> integer parameter (align 4, dereferenceable 8, etc)) and string<br>
attributes<br>
> (untyped in the IR - for target specific features).<br>
><br>
> The quirk of interest is that it seems integer attributes can all be<br>
> multiply specified (align 4 align 8 and dereferenceable 8<br>
dereferenceable 3)<br>
> - I'm not sure what this actually means (do we take the max? I<br>
assume we<br>
> do), but when I reached the Attribute sorting code it looks like<br>
it treats<br>
> these as distinct attributes at least and I wasn't sure if/how to<br>
cope with<br>
> this for a type attribute - should they be ordered (are Types<br>
orderable?)?<br>
> or should we be doing some kind of deduplication earlier on and<br>
say that<br>
> there's only one byval attribute (if I'm adding that machinery,<br>
should we<br>
> apply it to align, dereferencable, etc - I guess they get coalesced<br>
> /somewhere/ at least).<br>
><br>
> ______________________________<u></u>_________________<br>
> llvm-commits mailing list<br></div></div>
> <a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a> <mailto:<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.<u></u>edu</a>><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><span class=""><br>
><br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><br>
</span></blockquote>
<br>
</blockquote></div><br></div></div>