[PATCH] D28170: [LICM] When promoting scalars, allow inserting stores to thread-local allocas

Sanjoy Das via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 19 15:43:12 PST 2017


sanjoy added inline comments.


================
Comment at: llvm/trunk/lib/Transforms/Scalar/LICM.cpp:1037
     SafeToInsertStore =
-        isAllocLikeFn(Object, TLI) && !PointerMayBeCaptured(Object, true, true);
+        (isAllocLikeFn(Object, TLI) || isa<AllocaInst>(Object)) &&
+        !PointerMayBeCaptured(Object, true, true);
----------------
efriedma wrote:
> trentxintong wrote:
> > The question I really want to ask is whether the check for MayNotBeCaptured is necessary for Alloca. Should not alloca be implicitly thread local ? The language reference does not explicitly state it.
> In general, memory allocated using alloca can be used in all the same ways you could use memory allocated with malloc().  Not sure what sort of restriction you're expecting.
(Slight digression) There is one difference -- alloca memory is inherently frame local.  This means you don't have to worry about the memory escaping via a `ret`.  DSE handles a specific instance of this, where the stores are in the return block itself:

```
i8* @f() {
  %t = alloca i32
  store i32 42, i32* %t
  ret i32* %t
}
```

but e.g. slightly more complex cases like

```
define i32* @f(i1* %cond) {
  %t = alloca i32
  store i32 42, i32* %t
  %c = load volatile i1, i1* %cond
  br i1 %c, label %a, label %b

a:
  %c2 = load volatile i1, i1* %cond
  ret i32* %t

b:
  ret i32* null
}
```

are not handled by -O3.


Repository:
  rL LLVM

https://reviews.llvm.org/D28170





More information about the llvm-commits mailing list