llvm dev - Feb 2016 - How to force re-evaluate thread_local address?

Hi everyone,

I’m working on adding multithreading support to our programming language
(http://crystal-lang.org <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


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160201/499807b0/attachment-0001.html>

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>

On 1 February 2016 at 14:13, Sean Silva via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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).

Correct. This is pr19177.

Cheers,
Rafael