[llvm-dev] RFC: Adding argument allocas

[Friedman, Eli via llvm-dev]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161209/1f98407d/attachment.html>