[all-commits] [llvm/llvm-project] 59a467: [Coroutine] Make dealing with alloca spills more r...

[Xun Li via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 59a467ee4faeee5b569960e53a76a0311d050d18
      https://github.com/llvm/llvm-project/commit/59a467ee4faeee5b569960e53a76a0311d050d18
  Author: Xun Li <xun at fb.com>
  Date:   2020-09-08 (Tue, 08 Sep 2020)

  Changed paths:
    M llvm/lib/Transforms/Coroutines/CoroFrame.cpp
    M llvm/test/Transforms/Coroutines/coro-param-copy.ll

  Log Message:
  -----------
  [Coroutine] Make dealing with alloca spills more robust

D66230 attempted to fix a problem where when there are allocas used before CoroBegin.
It keeps allocas and their uses stay in put if there are no escapse/changes to the data before CoroBegin.
Unfortunately that's incorrect.
Consider this code:

%var = alloca i32
%1 = getelementptr .. %var; stays put
%f = call i8* @llvm.coro.begin
store ... %1
After this fix, %1 will now stay put, however if a store happens after coro.begin and hence modifies the content, this change will not be reflected in the coroutine frame (and will eventually be DCEed).
To generalize the problem, if any alias ptr is created before coro.begin for an Alloca and that alias ptr is latter written into after coro.begin, it will lead to incorrect behavior.

There are also a few other minor issues, such as incorrect dominate condition check in the ptr visitor, unhandled memory intrinsics and etc.
Ths patch attempts to fix some of these issue, and make it more robust to deal with aliases.

While visiting through the alloca pointer, we also keep track of all aliases created that will be used after CoroBegin. We track the offset of each alias, and then reacreate these aliases after CoroBegin using these offset.
It's worth noting that this is not perfect and there will still be cases we cannot handle. I think it's impractical to handle all cases given the current design.
This patch makes it more robust and should be a pure win.
In the meantime, we need to think about what how to completely elimiante these issues, likely through the route as @rjmccall mentioned in D66230.

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