This is similar to the allocfn case - if an alloca is not captured, then it's necessarily thread-local.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
| llvm/trunk/test/Transforms/LICM/promote-tls.ll | ||
|---|---|---|
| 67 | Any particular reason why this can not be br i1 undef, label %a, label %b ? Understandably, this can be simplified by SimplifyCFG or SCCP. but we are only running LICM here ? | |
| llvm/trunk/lib/Transforms/Scalar/LICM.cpp | ||
|---|---|---|
| 1037 | 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. | |
| llvm/trunk/lib/Transforms/Scalar/LICM.cpp | ||
|---|---|---|
| 1037 | 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. | |
| llvm/trunk/lib/Transforms/Scalar/LICM.cpp | ||
|---|---|---|
| 1037 | (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. | |
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.