<div dir="ltr">Moving this to llvm-dev where I should've sent it in the first place (& +Chandler, because we discussed this offline a bit)<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 19, 2015 at 11:32 AM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Thu, Feb 19, 2015 at 10:57 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Feb 19, 2015 at 8:31 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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?</blockquote></span></div></div></div></blockquote><div><br></div></span><div>I like this idea!</div></div></div></div></blockquote><div><br>So do I.<br><br>Chandler had some other thoughts that I'll attempt to express here:<br><br>* When you get right down to it, byval seems rather similar to alloca and global variables (they're all just some number of bytes with a required alignment)<br>* If we're changing byval should we change alloca and/or globals, too? (I'm a bit more of a pragmatist in this domain, and I'm not /too/ fussed about changing the one that's tricky (byval) and leaving the other two)<br>* We could just change their IR APIs to take a type but lower to bytes+alignment - textual/bitcode would be all size+alignment, but the C++ APIs for creating these constructs would still allow the user to pass in a type as a convenience. (Chandler suggested possibly keeping the textual IR allowing types to be specified - but the bitcode to be size+alignment, and deserializing that into a [i8 x N], but just supporting the C++ API seems sufficient to me but I hadn't thought of that in my conversation with him)<br><br>This does reflect part of the point of typeless pointers: that memory isn't typed, it's just bytes (and alignment). Globals, allocas, and byvals are all just that.<br><br>Does any of this sound important/reasonable?<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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<br></div></div></div></div></blockquote><div><br></div></span><div>Nope, we don't, we have an align attribute. =D </div></div></div></div></blockquote><div><br>Yep, seemed the align attribute wasn't always set in the frontend (& there's a comment in the backend where getByValTypeAlignment is called saying essentially "this is a fallback, it's not always correct, frontends should emit an align attribute if this isn't the behavior they want"). But PPC32 is the only one using a complex implementation of this function, everyone else, if they use it at all (which I think might be NVPTX and some others) just uses the default, which is the llvm::Type's alignment.</div></div><br>I'm working on moving this sort of thing to clang. The auto-upgrade might be a bit annoying, though (as we'll have to keep a bunch of that fallback logic around, but at least it'll just be in the auto-upgrader?)<br><br>- David</div></div>