Page MenuHomePhabricator

[StackSafety] Skip ambiguous lifetime analysis

Authored by vitalybuka on Jul 27 2020, 3:24 AM.



If we can't identify alloca used in lifetime marker we
need to assume to worst case scenario.

Diff Detail

Event Timeline

vitalybuka created this revision.Jul 27 2020, 3:24 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 27 2020, 3:24 AM
t.p.northover added inline comments.

Missing 'n' in "unknown"


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.

eugenis added inline comments.Jul 29 2020, 1:47 PM

Is this a tab character?

vitalybuka added inline comments.Jul 29 2020, 7:56 PM

Loop below sets Full range for uninteresting allocas, however with HasUnknowLifetimeStartOrEnd we can't be sure which are uninteresting,
Other than that I am not sure what are you asking.



eugenis added inline comments.Jul 30 2020, 1:30 PM

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.

eugenis accepted this revision.Jul 31 2020, 3:29 PM


This revision is now accepted and ready to land.Jul 31 2020, 3:29 PM
This revision was landed with ongoing or failed builds.Aug 6 2020, 7:10 PM
This revision was automatically updated to reflect the committed changes.
vitalybuka marked an inline comment as not done.
vitalybuka reopened this revision.Aug 7 2020, 2:00 PM
This revision is now accepted and ready to land.Aug 7 2020, 2:00 PM
This revision was automatically updated to reflect the committed changes.
ChuanqiXu added inline comments.

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.

vitalybuka added inline comments.Aug 26 2020, 2:25 PM

Is this theoretical or something produces such patterns?
I guess we will need to fallback to HasUnknownLifetimeStartOrEnd if life does not cover entire alloca.

ChuanqiXu added inline comments.Aug 26 2020, 6:34 PM

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.
My local fix for this problem is:

const AllocaInst *AI = llvm::findAllocaForValue(II->getArgOperand(1));


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.