<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 9, 2015 at 5:55 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<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"><span class=""><div class="gmail_quote">On Mon, Mar 9, 2015 at 1:23 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>byval and inalloca are edge cases where we can afford to sacrifice some readability.</div></blockquote></div><br></span>So, inalloca, maybe.</div><div class="gmail_extra"><br></div><div class="gmail_extra">But I don't see why byval is more or less relevant than anything else here. If it makes sense to keep the type is a convenience for readabie IR and such in 'alloca' (and I agree that it does), I feel like it makes sense for byval as well.</div></div>
</blockquote></div><br></div><div class="gmail_extra">Sure, I'd like to keep the type for both for readability, but I don't think it's worth adding support for attributes that can reference Types.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Another thing to think about is that llvm.memcpy calls today aren't typed, and we aren't trying to change that. byval is just a hidden memcpy, and as such it takes a size.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Or you could think of it as a hidden FCA load/store pair.</div></div>