Open kelbon opened 1 week ago
@llvm/issue-subscribers-coroutines
Author: None (kelbon)
Actually we never fix the issue foundamentally enough. We just banned merging TLS in coroutines in different optimizations one by one...
Actually we never fix the issue foundamentally enough. We just banned merging TLS in coroutines in different optimizations one by one...
Isn't this a bigger problem? May clang cache value of just global between co awaits? Or value of member in class ?
Yeah, that is a big problem.
BTW, this has nothing to do with clang but LLVM optimizations.
Yeah, that is a big problem.
BTW, this has nothing to do with clang but LLVM optimizations.
but why? If noinline function can prevent optimizations, why coroutine suspend cannot?
I feel the above problem can't be prevent by inserting noinline functions.
May clang cache value of just global between co awaits? Or value of member in class ?
Sorry to ignore this. It is not about globals nor member in classes, but some (middle end) functions are marked with pure attribute incorrectly. If you're interested, you can look at this https://discourse.llvm.org/t/address-thread-identification-problems-with-coroutine/62015/60
I feel the above problem can't be prevent by inserting noinline functions.
May clang cache value of just global between co awaits? Or value of member in class ?
Sorry to ignore this. It is not about globals nor member in classes, but some (middle end) functions are marked with pure attribute incorrectly. If you're interested, you can look at this https://discourse.llvm.org/t/address-thread-identification-problems-with-coroutine/62015/60
Not linked witih issue, just a question, do clang have optimization for awaiters which are not really awaiters?
Typical example is
struct get_handle {
std::coroutine_handle<> handle;
static bool await_ready() noexcept {
return false;
}
bool await_suspend(std::coroutine_handle<> h) noexcept {
handle = h;
return false;
}
std::coroutine_handle<> await_resume() noexcept {
return handle;
}
};
Its something standard forget to add, always false await_suspend or co_this
I have many of such awaiters in my coroutines, if it is not trivial to detect, may be add [[clang::never_suspend]] ?
commit where clang 18/19 fails: https://github.com/kelbon/kelcoro/pull/28/commits/541a84b207c62c19dbdbc5b35f4788f36cec7b19
code:
TP - thread pool
My workaround (after this test works as expected):
So, it is not first issue with caching thread local variables in coroutines, but now i think clang does not cache value of variable (load address), but anyway optimization thinks, that 'th_id' is equal to result of get_id