[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