[llvm-dev] lifetime.start/end

[Juneyoung Lee via llvm-dev]

BTW, I updated the LangRef patch (D94002). I hope it properly reflects the
consensus made so far.

Juneyoung

On Wed, Feb 10, 2021 at 6:14 PM Ralf Jung <jung at mpi-sws.org> wrote:

> Hi Johannes,
>
> >> 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?
>
> The fact that ASAN has to give up really gets to the core of the problem
> here:
> if even ASAN, *with full dynamic information*, cannot determine the
> lifetime of
> all alloca -- then clearly there is a gap somewhere in the specification.
> Every
> sufficiently precise specification would exactly determine what ASAN has
> to do
> to be 100% sure about the lifetime of all alloca.
>
> ASAN *can* determine the lifetime of some sublcass of alloca though,
> namely
> those that satisfy some syntactic restriction. The reason syntactic
> restrictions
> are being proposed is not that anyone likes them; the reason is that *they
> are
> the only proposal on the table* that achieves both:
> * Making the lifetime intrinsics actually affect the lifetimes of local
> variables.
> * Making the spec sufficiently precise that something like ASAN (with full
> runtime information) can exactly determine the lifetime of all alloca.
>
> Your alternative proposal of using lifetime markers only to affect the
> values
> stored in alloca does not achieve both of these goals; it gives up on the
> first
> point. That has its pros and cons (as we discussed before, I do not intend
> to
> reopen that discussion), but I hope we can agree that neither your
> proposal nor
> the current LLVM LangRef wording achieve both of the above points?
>
> Kind regards,
> Ralf
>
> >>
> >> 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/20210224/975d58d2/attachment.html>