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

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D132352#3757433 <https://reviews.llvm.org/D132352#3757433>, @ChuanqiXu wrote:

> 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.

Well, it's complicated.  Stackful coroutines don't generally involve creating a true thread, just a stack, and then yes, you swap the stack on the current thread in some system-specific way.  What I'm pointing out is that stackful coroutines can therefore observe changes in their thread ID across suspension points, which is the exact same problem as stackless coroutines have.  So we actually *would* need them to be identified specially, even if they're otherwise straightforward to compile, just so that we understand those special semantics and don't e.g. miscompile TLV accesses by hoisting them over a suspension.  (That this is still necessary might perhaps undermine some of the arguments for pursuing stackful coroutines in the first place; nonetheless, it's true.)

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

Sure, we don't need to talk about this any further, since nobody's interested in pursuing it right now.  I'm just trying to underline the connections to what we've already done.


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

https://reviews.llvm.org/D132352