[all-commits] [llvm/llvm-project] 352216: [Coroutine] Properly deal with byval and noalias p...

[Xun Li via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 3522167efd80e2fef42a865cdf7481d60d062603
      https://github.com/llvm/llvm-project/commit/3522167efd80e2fef42a865cdf7481d60d062603
  Author: Xun Li <lxfind at gmail.com>
  Date:   2021-06-17 (Thu, 17 Jun 2021)

  Changed paths:
    M llvm/lib/Transforms/Coroutines/CoroEarly.cpp
    M llvm/lib/Transforms/Coroutines/CoroFrame.cpp
    A llvm/test/Transforms/Coroutines/coro-byval-param.ll
    A llvm/test/Transforms/Coroutines/coro-noalias-param.ll

  Log Message:
  -----------
  [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