If we can't identify alloca used in lifetime marker we
need to assume to worst case scenario.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/include/llvm/Analysis/StackLifetime.h | ||
---|---|---|
124 | Missing 'n' in "unknown" | |
llvm/lib/Analysis/StackLifetime.cpp | ||
301 | Doesn't this case need the loop below? It looks like it's undoing all the extra default initialization caused by the resize. Actually, I'd be inclined to reword the whole thing in terms of resizing with the default and separately setting NumAllocas - 1 if that is the correct reading. |
llvm/test/Analysis/StackSafetyAnalysis/lifetime.ll | ||
---|---|---|
781–836 | Is this a tab character? |
llvm/lib/Analysis/StackLifetime.cpp | ||
---|---|---|
301 | I think Vitaly's right, if we see a lifetime that can't be traced back to an alloca, we have no way of knowing which allocas are "not interesting" and must handle all of them conservatively. |
llvm/lib/Analysis/StackLifetime.cpp | ||
---|---|---|
78 | Maybe we can't use findAllocaForValue to find alloca for lifetime marker. Here I find a pattern: a = alloca struct ... b = getelementptr from a lifetime start (b) /// ... lifetime end (b) And the code here would treat the lifetime span of b, which is part of a, as the whole lifetime of a. But the lifetime span of other component of a may not be the same with the lifetime span of b. I think it may cause mismatch. |
llvm/lib/Analysis/StackLifetime.cpp | ||
---|---|---|
78 | Is this theoretical or something produces such patterns? |
llvm/lib/Analysis/StackLifetime.cpp | ||
---|---|---|
78 | I don't find theoretical who produces this pattern. I find such pattern by using StackLifetime in practice. The pattern seems like related to Coroutine Elision which would put one Coroutine Frame structure into another Coroutine Frame. But I don't sure if there is any other situation where would produce similar patterns. const AllocaInst *AI = llvm::findAllocaForValue(II->getArgOperand(1)); into auto *OpInst = dyn_cast<Instruction>(II->getOperand(1)); auto *AI = dyn_cast<AllocaInst>(OpInst->stripPointerCasts()); which would fallback to HasUnknownLifetimeStartOrEnd if lifetime marker doesn't cover entire alloca as you say. |
Missing 'n' in "unknown"