Is it possible to do a call "call i32 @llvm.wasm.tls.size.i32()" from an assembly .S file?

[juj]

In LLVM we have the built-ins

https://github.com/llvm-mirror/clang/blob/aa231e4be75ac4759c236b755c57876f76e3cf05/test/CodeGen/builtins-wasm.c#L41-L51

I would like to call these built-ins directly from a WebAssembly asm .S file. However I am not sure what (if any?) the syntax would be. Trying something like

initialize_tls:
  .functype initialize_tls() -> ()

  .functype llvm.wasm.tls.size.i32 () -> (i32)
  call llvm.wasm.tls.size.i32

  end_function

does not work, but simply yields an undefined external function declaration. Trying some variations by replacing .s with _s does not give much help either.

Anyone knows if it would be possible to call these built-ins from a Wasm assembly .S file? The reason I need to do that is that I want to call out to get the TLS size (and alignment) before I have established a stack frame for the thread, so I cannot call in to C/C++ code to do that, because that would try to do stack pointer push/pop operations on a stack pointer that does not yet exist.

@sbc100 @tlively @dschuff ?

[sbc100]

You need to find that actual C symbol that the llvm builtin resolves to.

One way to do this is to take a C file such as system/lib/pthread/emscripten_tls_init.c which calls those intrinsics and run llvm-nm on that resulting object file:

$ llvm-nm ./cache/sysroot/lib/wasm32-emscripten/crtbegin.o
         U __tls_align
         U __tls_size
         U __wasm_init_tls

Here you can see there are 3 undefined C symbols, two are wasm-global symbols (__tls_align and __tls_size) (not that these are different to data symbols which are address in linear memory rather than wasm globals) and one is a function symbol (__wasm_init_tls).

For wasm-global symbols you can reference them in .s file simply by delaring either type (with .globaltype) and then using them in global.get instruction.

[sbc100]

BTW I would hope that system/lib/pthread/emscripten_tls_init.c is usable for wasm workers.. and should not need and alternative implementation since its very generic code.

[sbc100]

Another BTW: the above 3 symbols that start with __ are generated by the linker as needed.

[juj]

Thanks! I see that __tls_size is then actually a constant and not a function.. so I try something like this:

  local.get 0
  .globaltype __tls_size, i32
  i32.const __tls_size
  i32.sub
  .functype __wasm_init_tls (i32) -> ()
  call __wasm_init_tls

but I get an error:

E:\code\emsdk\llvm\git\build_main_vs2019_64\Release\bin\llvm-ar.exe: error:
E:\\code\\emsdk\\emscripten\\main\\cache\\sysroot\\lib\\wasm32-emscripten\\libcompiler_rt-ww.a: invalid relocation data index

I wonder if there is a way around this?

Unfortunately emscripten_tls_init.c is not interesting for this purpose, since it relies on dynamic memory allocation and two-stage stack+tls setup. I am trying to see if I can generate both the stack and the tls in one function, without having to pass the tls slot size from main thread to the worker as well.

[sbc100]

Thanks! I see that __tls_size is then actually a constant and not a function.. so I try something like this:

  local.get 0
  .globaltype __tls_size, i32
  i32.const __tls_size
  i32.sub
  .functype __wasm_init_tls (i32) -> ()
  call __wasm_init_tls

It's a wasm global so you need to use global.get to retrieve it.

but I get an error:

E:\code\emsdk\llvm\git\build_main_vs2019_64\Release\bin\llvm-ar.exe: error:
E:\\code\\emsdk\\emscripten\\main\\cache\\sysroot\\lib\\wasm32-emscripten\\libcompiler_rt-ww.a: invalid relocation data index

I wonder if there is a way around this?

Unfortunately emscripten_tls_init.c is not interesting for this purpose, since it relies on dynamic memory allocation and two-stage stack+tls setup. I am trying to see if I can generate both the stack and the tls in one function, without having to pass the tls slot size from main thread to the worker as well.

OK. Can I ask that any of the optimization that possible could apply to pthreads are also applied there? Even better sharing code where possible. I'm a little worried about (a) (avoidable) divergence, and (b) duplication of optimization efforts (since we are very interested optimizing the pthread use case too.

[juj]

It's a wasm global so you need to use global.get to retrieve it.

Ohh thanks hmm, I think that I tried that - but maybe I messed something up. I'll give that another go.

OK. Can I ask that any of the optimization that possible could apply to pthreads are also applied there? Even better sharing code where possible. I'm a little worried about (a) (avoidable) divergence, and (b) duplication of optimization efforts (since we are very interested optimizing the pthread use case too.

I agree that sharing code is a useful goal, and optimizing pthreads size is also useful. However these are just about a few silly lines and a function or two, so even if they diverge, it won't be a big deal at all - the cognitive complexity is still super small.

I am all for sharing code, but in situations like this where the sharing is "almost trivial", I find that ensuring minimal code size, developer velocity and flexibility of refactoring greatly trumps. Sharing code -> more inter-dependencies -> more friction to refactor. (once need to iterate "cools" down, sharing code -> more cohesion -> less cognitive overhead begins to help more instead)

It is certainly good to go towards that eventual goal where both share the same implementation, though for now being able to iterate and experiment helps me much more to get the code polished exactly to the way it feels it should look like.

[juj]

It's a wasm global so you need to use global.get to retrieve it.

When I tried global.get, I was getting the error

wasm-ld: error: Global type mismatch: __tls_size
>>> defined as const i32 in <internal>
>>> defined as var i32 in E:\code\emsdk\emscripten\main\cache\sysroot\lib\wasm32-emscripten\libcompiler_rt-ww.a(stack_limits.o)

That const there threw me off to interpreting it would then somehow use i32.const.. but now I realize that I was missing the keyword immutable when declaring the globaltype, i.e.

  .globaltype __tls_size, PTR, immutable

Got this working now in PR #16476. Thanks for the help!