<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 17, 2013 at 2:11 PM, Nick Lewycky <span dir="ltr"><<a href="mailto:nlewycky@google.com" target="_blank">nlewycky@google.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">On 16 December 2013 14:03, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote"><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">

<div dir="ltr">PTAL?</div></blockquote><div><br></div><div>+    The caller must pass in an alloca value into an ``inalloca``<br></div><div>+    parameter, and an alloca may be used as an ``inalloca`` argument at</div><div>


+    most once.  The ``inalloca`` attribute cannot be used in conjunction</div><div class="im"><div>+    with ``byval``, ``readonly``, and others. These rules are enforced</div><div>+    by the verifier.</div><div><br></div>
</div><div>Why is inalloca forbidden in conjunction with readonly, and which others? Noalias? Nocapture? What about "nest"? "returned"?</div></div></div></div></blockquote><div><br></div><div>OK, I'll make it a complete list.  It's basically readonly plus the standard list of ABI attributes: sret, nest, returned, inreg, and byval.  sret and returned could work, but are fairly nonsensical.</div>
<div><br></div><div>Readonly deserves it's own explanation.</div><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 realize that after a call the alloca must be assumed to have been clobbered, but what if the callee doesn't contain IR to perform said clobbering? An optimization would them go ahead and add the readonly attribute, and that would transform valid IR to invalid IR. I think this state should be permitted even though it indicates something nonsensical (this is not the only place in the IR we permit contradictory things just because we don't want to put the burden on the optimizer to check all possible cases.)</div>
</div></div></div></blockquote><div><br></div><div>If I understand correctly, your desired end state is that optimizations should be taught to avoid creating inalloca+readonly parameters, but the verifier should not enforce this.  Is that right?</div>
<div><br></div><div>My intention was to outlaw inalloca+readonly, change the verifier, and then use that to find and fix optimizations doing this.</div><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>+      Assert1(!Attrs.hasAttribute(Idx, Attribute::ByVal) &&<br></div><div><div>+              !Attrs.hasAttribute(Idx, Attribute::InAlloca),</div>
<div>+              "Attribute 'byval' and 'inalloca' do not support unsized types!",</div>

<div>+              V);</div></div><div><br></div><div>"Attribute" --> "Attributes". Yes, I'm aware that pushes you over the 80 column limit.</div></div></div></div></blockquote><div><br></div>
<div>*shrug* clang-format says it's fine.  :)</div><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>LG</div></div></div></div></blockquote><div><br></div><div>Based on this, I'm going to commit the LangRef change and send along followups.  We can reevaluate what we're doing with readonly when you're back from vacation some time before the next release.</div>
<div><br></div><div>Thanks for the review!</div></div></div></div>