[PATCH] D61461: When removing inalloca, convert to static alloca
Reid Kleckner via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu May 2 16:17:05 PDT 2019
rnk added a comment.
In D61461#1488801 <https://reviews.llvm.org/D61461#1488801>, @efriedma wrote:
> An example of what I'm talking about with multiple calls:
>
> struct C { C() noexcept; C(const C&) noexcept; ~C() noexcept; };
> void f(C) noexcept, f2(C) noexcept;
> void g(bool b, bool b2) { if (b2) { b ? f(C()) : f2(C()); } }
>
>
> With "clang -O2 --target=i686-pc-windows-msvc -emit-llvm", there's one alloca used by multiple calls; the alloca can't be hoisted until both inalloca attributes are stripped.
Right, that test case. It was even in the design doc. If only we'd had token at the time. :(
So, we'd have to analyze the uses of the alloca to prove this transform is valid. But, this is kind of nasty since you can take an alloca, bitcast it, gep forwards, store that, reload it, gep back, and then use that as an argument to an inalloca call, and that should be valid IR.
It's actually important to optimize the case where the inalloca parameter escapes via a call and there is some control flow, since typically the reason we're emitting inalloca in the first place is because we have to call a nontrivial constructor. So, we'd want to be able to say that it's not valid to pass an inalloca pointer to a call, return it back, and then use it as an argument pack. I don't know if we can make that semantic change. We have things like the IR outliner that wouldn't know about that, although they wouldn't intentionally try to obscure other uses of a captured alloca.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D61461/new/
https://reviews.llvm.org/D61461
More information about the llvm-commits
mailing list