[llvm-dev] RFC: Adding argument allocas

[Hal Finkel via llvm-dev]

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

> From: "Eli via llvm-dev Friedman" <llvm-dev at lists.llvm.org>
> To: "Reid Kleckner" <rnk at google.com>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Friday, December 9, 2016 12:30:34 PM
> Subject: Re: [llvm-dev] RFC: Adding argument allocas

> On 12/9/2016 8:45 AM, Reid Kleckner wrote:

> > On Thu, Dec 8, 2016 at 5:37 PM, Mehdi Amini < mehdi.amini at apple.com
> > >
> > wrote:
> 

> > > So IIUC basically the *only* reason for this IR change is that we
> > > don’t want to pattern match in debug build?
> > 
> 
> > > I don't understand right now why we wouldn’t want to do this?
> > 
> 
> > If we need to pattern match such a basic construct, it suggests to
> > me
> > that we have the wrong representation, and we should instead make
> > our representation more accurately model reality. To me, it feels
> > like this representation allows several good things to just "fall
> > out" without any additional work, and that suggests it's a good
> > representation.
> 
> Mmm... maybe. The part I really don't like is the implied store:
> there are a lot of transformations which specifically reason about
> store instructions, and they would all need to be fixed to
> specifically deal with "alloca with an argument" so it doesn't block
> optimizations.
I'm not sure this is true. The instruction does write to memory, at least formally, but by definition the address of the alloca cannot yet have been used by anything else, and so no other memory access can alias with it. The write also can't trap. The alloca, as a result, does not even need to be tagged as writing to memory. 

-Hal 

> Every feature we add to the IR makes it more difficult to write IR
> transformations, and this really doesn't seem to carry its own
> weight.

> A couple of other thoughts I had:
> 1. We could use metadata, e.g. "%px = alloca i32, align 4 !argument
> !i32 %x", followed by a store. There's still a little
> pattern-matching involved because the metadata is only a hint, but
> the intent in the IR is more explicit.
> 2. We could change the way clang generates function definitions:
> instead of "define void @f(i32 %x)", generate "define void @f(i32*
> byval %px)" if the value is going to end up on the stack. This
> should work without any changes to the IR. This is a bad idea if
> we're trying to run optimizations because it obscures data flow, but
> it seems reasonable at -O0.

> -Eli
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 

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/20161210/53c5436d/attachment.html>