
<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Reid Kleckner" <rnk@google.com><br><b>To: </b>"Hal Finkel" <hfinkel@anl.gov><br><b>Cc: </b>"llvm-dev" <llvm-dev@lists.llvm.org><br><b>Sent: </b>Monday, December 12, 2016 5:03:08 PM<br><b>Subject: </b>Re: [llvm-dev] RFC: Adding argument allocas<br><br><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Dec 10, 2016 at 8:20 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);">Having an alloca with an initializer seems like a reasonable enhancement. Please, however, without all of these special restrictions: any value should be accepted on any alloca. We can match the special argument cases in the backend and otherwise lower to the equivalent of an alloca+store.</div></div></blockquote><div><br></div><div>We can definitely generalize this to alloca initializers, but there's very little reason for frontends to initialize allocas that aren't arguments. Typically allocas for locals must live in the entry block, while initialization might be buried in some conditionally executed code. A frontend would have to know that the initializer doesn't depend on local computation, and that hoisting the store to the entry block doesn't pessimize the code. With arguments, the value is always available, and the notional store will be optimized away or is needed in a debug build.</div><div><br></div><div>So, even though I think arbitrary alloca initializers are a reasonable extension to the LLVM IR model, I don't see enough of a use case to add the general feature. I'd rather have a feature that does one thing well rather than trying to be overly general (e.g. llvm.lifetime.start).</div></div></div></div>

</blockquote>Obviously there are tradeoffs here, but I think this is more of a language design issue than a feature-set issue. If the core IR syntax becomes full of these kinds of (unnecessary) restrictions then we've lost something valuable. I think that the fact that we're talking about a core part of the IR, not some attribute or limited-purpose intrinsic, is important here. The generalization here is obvious and simple to implement. If we only support certain arguments, then we'll end up with special code in the frontends to detect the relevant situations, more code for validation and assertions, etc. Because these alloca initializers are much easier to analyze in terms of aliasing properties, I can imagine wanting to emit them whenever possible.<br><br>Thanks again,<br>Hal<br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Lead, Compiler Technology and Programming Languages<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>