[llvm-dev] lifetime.start/end

[Juneyoung Lee via llvm-dev]

On Wed, Feb 10, 2021 at 1:40 AM Johannes Doerfert <
johannesdoerfert at gmail.com> wrote:

> On 2/8/21 11:46 PM, Juneyoung Lee wrote:
> > Hi,
> >
> > About syntactic constraints - I think it can be helpful for
> transformations
> > that need to be fully aware of all allocations' lifetimes.
> > For example, AddressSanitizer is currently simply giving up instrumenting
> > things if there is an unknown lifetime usage.
> > If all lifetime intrinsics' pointers are guaranteed to be known
> > expressions, this issue is resolved.
>
> It is "resolved" by disallowing more complex use cases. To hyperbolize
> an analogy: Constant propagation could avoid almost all of its
> checks/analysis
> if we restrict all expressions to be constant 0. I know this is not the
> same
> thing but I hope you see where I'm getting at. The proper solution for ASAN
> is to check if it can handle the lifetime markers and not utilize them
> otherwise.
> If they happen to fall in the proposed syntactic restrictions I assume ASAN
> can already handle them fine anyway, right?
>

Yep, it falls back to the conservative mode.
But, I'm still in favor of explicitly giving a guideline describing what
the pointer argument
of lifetime.start/end looks like; otherwise transformations that use
lifetime should
speculate on their own about the shape of the pointer arguments.

What about starting with writing e.g.,
ValueTracking::isCanonicalLifetimeStart(IntrinsicInst *I) (and for
lifetime.end as well),
that checks whether I is lifetime.start(p) where p is a known form?
p should be one of alloca / bitcast(alloca) / ... and anything that may
appear during transformations in
O3 pipeline.
Passes can use this function if they want and get a guarantee that they are
not missing any form
of lifetime that appears in the pipeline, which is great.
It is up to the pass whether it will crash or fallback to a conservative
mode if isCanonicalLifetimeStart
returned false.



> >
> > if (HasUntracedLifetimeIntrinsic) {
> > // If there are lifetime intrinsics which couldn't be traced back to an
> > // alloca, we may not know exactly when a variable enters scope, and
> > // therefore should "fail safe" by not poisoning them.
> > StaticAllocaPoisonCallVec.clear();
> > DynamicAllocaPoisonCallVec.clear();
> > }
> >
> > Interestingly, AddressSanitizer is the one that raises an issue as well
> if
> > the syntactic restriction is enforced.
> > It replaces allocas with __asan_stack_malloc_N, but still leaves its
> > lifetime uses, which breaks the syntactic restriction. A possible
> solution
> > for this is to simply remove the lifetime calls.
>
> I can't stress this enough, syntactic restrictions are rarely helpful.
> Now we are talking about dropping information because of it. We seem
> to have also fond a non-stack memory user, great.
>
> ~ Johannes
>
>

-- 

Juneyoung Lee
Software Foundation Lab, Seoul National University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210210/4d0fa96f/attachment.html>