[PATCH] D75664: [Coroutines] Also check lifetime intrinsic for local variable when build coroutine frame

JunMa via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 5 18:04:50 PST 2020


junparser added a comment.

In D75664#1908825 <https://reviews.llvm.org/D75664#1908825>, @junparser wrote:

> In D75664#1907758 <https://reviews.llvm.org/D75664#1907758>, @wenlei wrote:
>
> > Nice change, thanks @junparser! The improved dataflow analysis using lifetime instead of allocation point and the resulting shrink-wrapping style opt for alloca would definitely be beneficial.
> >
> > For data race however, I'm not sure if I understand it correctly, could you elaborate (perhaps with a concrete example..) why this is compiler's fault?
>
>
> For
>
>   auto await_suspend(std::experimental::coroutine_handle<> h) {
>       auto& pr = h.promise();
>       if (pr._ex) {
>           // schedule to another thread
>           pr._ex->schedule([&pr]() {
>               pr._continuation.resume();
>           });
>       }
>   }
>   
>
> This case shows data race with inline, and does not when not inlined. It looks like both the current thread and schedule thread  access some fields of std::function when I dig into the ir. I'm not sure whether this is caused by std::function constructor/destructor or move allocas to frame. I get such conclusion based on ir.


More specifically, the tsan gives 'use after free' error.  So I think tsan can trace such access of frame block, but it may not be able to trace local allocas.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75664/new/

https://reviews.llvm.org/D75664





More information about the llvm-commits mailing list