[PATCH] D104007: [BasicAA] Properly mark that coroutine suspension may modify parameters
Chuanqi Xu via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Jun 10 23:32:52 PDT 2021
ChuanqiXu added a comment.
>From my point of view, the difference comes from:
- @lxfind and me think this patch could solve bug 48857 well.
- @efriedma think that coroutine suspend wouldn't make alloca really 'may alias'. We are just trying to make a lie to the MemCpyOpt Pass.
Is it the main difference until now?
So here is my thought about the reason why this patch isn't a lie. Let's start from bug 48857, why is the transformation made by MemCpyOpt pass wrong? I think the root reason is that the introduce of coroutine breaks the data flow! For example, (use pseudo code for simplicity. Remind me if any thing is confusing )
void foo(int a) {
%a.tmp = alloca ...
%b = alloca ...
copy %a to %a.tmp
coro.suspend
copy %a.tmp to %b ...
use of %b
}
would be splited to:
void foo.ramp(int a);
void foo.resume(%foo.Frame);
And if all the caller of foo, calls foo.resume immediately foo.ramp, everything should be right. However, the actual behavior of the program between foo.ramp and foo.resume is undetermined. In other words, there may be any instruction executed between foo.ramp and foo.resume. From the side of static analysis, it looks like there is a call to function without definition known at compile time in every coro.suspend call.
So it looks natural to mark arguments may alias after coro.suspend to me. How do you think about it?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D104007/new/
https://reviews.llvm.org/D104007
More information about the llvm-commits
mailing list