[PATCH] D132352: Introduce noread_thread_id to address the thread identification problem in coroutines

[Chuanqi Xu via Phabricator via llvm-commits]

ChuanqiXu added a comment.

In D132352#3757415 <https://reviews.llvm.org/D132352#3757415>, @rjmccall wrote:

> Stackful coroutine bodies should be straightforward to support on top of the other work you've been doing, if anyone's actually interested in pursuing them.  As far as the optimizer needs to know, a stackful coroutine function is just like a presplit stackless coroutine except that calls and returns work normally and it's never split.  Because it's never split, the backends would need to understand that they can't arbitrarily reorder TLS materializations and so on in those functions, which would probably be the most complicated piece of work there.  Otherwise, I think we'd just need to mark stackful coroutine bodies with some new attribute and then change `cannotReadDifferentThreadIDIfMoved` to check for that, the same way it checks for presplit stackless coroutines.

As far as I understand, we can't mark stackful coroutine bodies with special attributes. It is slightly different from stackless coroutine. A stackless coroutine is a suspendable function. So we can mark the function. But the stackful coroutine is a thread in the user space actually. (Or we can think stackful coroutine as a stack instead of a function)  In another word, if a function A in a stackful coroutine calls another function B, then B lives in the stackful coroutine too. The stackful coroutine switches by user(library) implemented methods and they are not standardized so we can't even do hacks for them.

I don't pursue stackful coroutine too. I raise the example to show the idea of `noread_thread_id` may have some slight advantage.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132352/new/

https://reviews.llvm.org/D132352