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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
