<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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000">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>