[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