[llvm-bugs] [Bug 50789] New: Cherry-pick 3522167efd80e2fef42a865cdf7481d60d062603 to release/12.x

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50789

            Bug ID: 50789
           Summary: Cherry-pick 3522167efd80e2fef42a865cdf7481d60d062603
                    to release/12.x
           Product: new-bugs
           Version: 12.0
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: lxfind at gmail.com
          Reporter: lxfind at gmail.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org
            Blocks: 49317

Please cherry-pick this to the 12.x releases:

commit 3522167efd80e2fef42a865cdf7481d60d062603
Author: Xun Li <lxfind at gmail.com>
Date:   Thu Jun 17 19:06:10 2021 -0700

    [Coroutine] Properly deal with byval and noalias parameters

    This patch is to address https://bugs.llvm.org/show_bug.cgi?id=48857.
    Previous attempts can be found in D104007 and D101980.
    A lot of discussions can be found in those two patches.
    To summarize the bug:
    When Clang emits IR for coroutines, the first thing it does is to make a
copy of every argument to the local stack, so that uses of the arguments in the
function will all refer to the local copies instead of the arguments directly.
    However, in some cases we find that arguments are still directly used:
    When Clang emits IR for a function that has pass-by-value arguments,
sometimes it emits an argument with byval attribute. A byval attribute is
considered to be local to the function (just like alloca) and hence it can be
easily determined that it does not alias other values. If in the IR there
exists a memcpy from a byval argument to a local alloca, and then from that
local alloca to another alloca, MemCpyOpt will optimize out the first memcpy
because byval argument's content will not change. This causes issues because
after a coroutine suspension, the byval argument may die outside of the
function, and latter uses will lead to memory use-after-free.
    This is only a problem for arguments with either byval attribute or noalias
attribute, because only these two kinds are considered local. Arguments without
these two attributes will be considered to alias coro_suspend and hence we
won't have this problem. So we need to be able to deal with these two
attributes in coroutines properly.
    For noalias arguments, since coro_suspend may potentially change the value
of any argument outside of the function, we simply shouldn't mark any argument
in a coroutiune as noalias. This can be taken care of in CoroEarly pass.
    For byval arguments, if such an argument needs to live across suspensions,
we will have to copy their value content to the frame, not just the pointer.

    Differential Revision: https://reviews.llvm.org/D104184


Referenced Bugs:

https://bugs.llvm.org/show_bug.cgi?id=49317
[Bug 49317] [meta] 12.0.1 Release Blockers
-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210621/a8f02a90/attachment.html>