[llvm-dev] How to force re-evaluate thread_local address?

[Sean Silva via llvm-dev]

IIRC, this is a long-standing issue and some of our game teams that use
coroutine-like job systems run into this as well. My recollection is that
it is a big pile of work to fix this in the llvm backend. The workaround is
to do all thread-local access via functions that access thread-local state
and do not do any context-switching (and these functions must not be
inlined, obviously).

-- Sean Silva

On Mon, Feb 1, 2016 at 9:25 AM, Juan Wajnerman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi everyone,
>
> I’m working on adding multithreading support to our programming language (
> http://crystal-lang.org) and I’m facing an issue with thread local
> variables.
> Since the language relies heavily on coroutines, basically the problem is
> that a function could start running on a thread, get suspended and continue
> running on a different thread.
>
> So, for example, if I have this pseudocoe:
>
> 1. read / write thread local variable
> 2. do some context switch, might resume in a different thread
> 3. read / write same thread local variable
>
> Now the real issue is that when compiling with optimizations, LLVM wont
> re-read the thread local address, and instead it will rely on the address
> stored on some register.
>
> The question is: is there any way to force LLVM to re-read the thread
> local address each time? Or even better, is there any way to give hints
> about where the cached address is not reliable anymore?
>
> Best regards!
> - Juan
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160201/bcca9531/attachment.html>