[llvm-dev] RFC: Adding argument allocas

[Reid Kleckner via llvm-dev]

On Fri, Dec 9, 2016 at 10:30 AM, Friedman, Eli <efriedma at codeaurora.org>
wrote:

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

I don't feel like it complicates our model that much, though. Passes
already have to know that uninitialized allocas contain undef, and with
this change they can contain a value. That doesn't seem very surprising. It
is a fair point that we'd have to add new cases to code
like llvm::FindAvailableLoadedValue, which looks for StoreInst but not
AllocaInst.


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

This works, but it doesn't feel like it keeps simple things simple. I'll
definitely implement this if people don't like my proposal.


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

This is problematic because it would break out "bitcode ABI" between
optimized and debug builds. We've had problems in the past when the caller
and callee disagree on whether an argument is a byval pointer or not, and
instcombine will come along and try to simplify the casts:
https://llvm.org/bugs/show_bug.cgi?id=21573
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161209/2e28d7b8/attachment.html>