[llvm-dev] RFC: Adding argument allocas

[Hal Finkel via llvm-dev]

----- Original Message -----

> From: "Reid Kleckner" <rnk at google.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Monday, December 12, 2016 5:03:08 PM
> Subject: Re: [llvm-dev] RFC: Adding argument allocas

> On Sat, Dec 10, 2016 at 8:20 AM, Hal Finkel < hfinkel at anl.gov >
> wrote:

> > 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.
> 
> 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.

> 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).
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. 

Thanks again, 
Hal 

-- 

Hal Finkel 
Lead, Compiler Technology and Programming Languages 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161212/2f037847/attachment.html>