[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