[WebAssembly] __table_base should not be optimized into locals (wasm locals or stack locals)

[mf-RDP]

__table_base is currently defined as a non mutable global. However, think of a specific implementation that works with BOTH native and wasm (integer) function pointers - just as an example.

For global_get & global_set, their implementations could do complex modifications of the returned value (mimicked __table_base) in conjunction with call_indirect.

This works well, I did actually implement such a thing.

However, it gets broken by the following compiler optimization:
global_get(__table_base)
local_tee(42) <<<<---
i32_add(142)
call_indirect()
local_get(42)
i32_add(143)
call_indirect()

I think, as __table_base can be a highly sophisticated, implementation specific thing, it would be good not to intern it into locals.

the code above should best look like this
global_get(__table_base)
i32_add(142)
call_indirect()
global_get(__table_base) <<<<---
i32_add(143)
call_indirect()

I would say that introduced overhead is none, or absolutely minimal.

[llvmbot]

@llvm/issue-subscribers-backend-webassembly

Author: None (mf-RDP)

__table_base is currently defined as a non mutable global. However, think of a specific implementation that works with BOTH native and wasm (integer) function pointers - just as an example.

For global_get & global_set, their implementations could do complex modifications of the returned value (mimicked __table_base) in conjunction with call_indirect.

This works well, I did actually implement such a thing.

However, it gets broken by the following compiler optimization:
global_get(__table_base)
local_tee(42) <<<<---
i32_add(142)
call_indirect()
local_get(42)
i32_add(143)
call_indirect()

I think, as __table_base can be a highly sophisticated, implementation specific thing, it would be good not to intern it into locals.

the code above should best look like this
global_get(__table_base)
i32_add(142)
call_indirect()
global_get(__table_base) <<<<---
i32_add(143)
call_indirect()

I would say that introduced overhead is none, or absolutely minimal.

[sbc100]

First of all, __table_base is only used in dyanmic linking (i.e. -fPIC code). Are you actually using dyanmic linking or could your use case avoid this issue by not using dynamic linking.

But more importantly since __table_base is immutable it should be perfectly valid it do any kind of caching and optimizing. __table_base should just be a normal wasm global that hold the offset into the table at which the segments live. Perhaps I'm not understanding what you mean by "complex modifications of the returned value".

Furthermore, even if llvm didn't cache this value its perfectly valid for optimizers such as wasm-opt to do this caching since there is nothing special about __table_base at the Wasm level.. its just a normal wasm global.

[mf-RDP]

Ok, thanks. I already expected that there would not be very much understanding for my point.
I will close this one shortly.

BUT, Btw. do you (or anyone reading) know where to modify LLVM to avoid these optimizations? Just bringing __table_base to mutable in getOrCreateWasmSymbol (+ another place, I forgot), did NOT work.

[mf-RDP]

So, what bothers me a bit is, that, after making __table_base mutable (locally in my LLVM repo), the assembly is still the same, for example take

(func $vfprintf (type 11) (param i64 i64 i64) (result i32) (local i64) local.get 0 local.get 1 local.get 2 global.get $__table_base local.tee 3 i64.const 78 i64.add local.get 3 i64.const 79 i64.add call $__vfprintf_internal)
I think this happens in WebAssemblyCFGStackify.cpp or in that Reg Stackify - could that be?

Just to clarify - I do not want to avoid anything, everything works fine, yes, I want to extend functionality.

[sbc100]

If you are on a platform where supporting __table_base is tricky I would recommend just completely avoiding it by avoiding -fPIC .. is that an option for you?

[dschuff]

If I'm understanding you correctly, it sounds like your wasm implementation tries to specially recognize global.get/call_indirect pairs using __table_base and does something special under the hood (presumably redirecting the call to some native function). I think if you're implementing a system like that, you need to make sure that the wasm code and implementation you're using is spec-compliant, otherwise as sbc100 mentioned, some optimization or transform is always going to break you. You might be able to selectively find ways to disable them, but your system will always be very brittle. For example in this case, since table_base is just an integer it's always valid to do anything to it that's valid for an integer; tee it into a local, do arithemetic, etc. Function pointers are always just integers.

[sbc100]

So, what bothers me a bit is, that, after making __table_base mutable (locally in my LLVM repo), the assembly is still the same, for example take

Regardless of the mutability of a global is still valid to cache its value within a given function since globals are not shared between threads and can have no outside mutation. (Obviously if you call an import it can change, but aside from that all the mutations will be from global.set within the module).

[mf-RDP-two]

[I'm the OP of this issue, shame on me, thanks to some incompetent legacy mail provider I lost the original github account]

Yes, dschuff, exactly!! Thank you so much for understanding my point, that's exactly what I have done. The idea is, of course you can in C:
void (*native_funcptr)(abc) = __some_VM_intrinsic_function_make_native_function_pointer(&wasm_function)
but it should work without the extra call,
just like
void (*native_funcptr)(abc) = &wasm_function

So, I did as described. It works well, actually. But of course, as you said, it is just no clean solution - of course I know that.
However, I want to make it a clean solution!

One way would be if global.get(__table_base) is not optimized into locals, memory stores, etc.
And I must say I'm a bit astonished that it's just said, even if it's mutable, it can be optimized - I mean, we're talking about an IMPORTED mutable global, a thing, a VM should be able to modify, interfere with. ([1])

Another way would be to replace global.get(__table_base) by some builtin library function like builtin_wasm_get_function_addr(offset), but I think that's much more effort.

I would be ready to implement this into the WASM backend (with some -mllvm option, or similar). Does anyone want to advise? I think, it's a thing generally good to have, think of my point [1]. It's not just an emscripten world ;)

I found out it should likely be done in LowerGlobalAddress. However, I did not yet find out how to tell it that that symbol is 'volatile', somehow. Maybe anyone can adivse? So at least I could do it in my LLVM trunc (and maybe PR later).

[mf-RDP-two]

For me, I solved this now by an intrinsic, custom makelibcall. I think this topic (__table_base non-optimization) should really be considered. Generally, these are very good concepts (LLVM + Wasm Backend) overall, but the fact that a VM cannot interfere with these variables is a needless limitation.

[dschuff]

I don't think what you're asking for is really consistent with the spec as it currently is.
Just because a global is imported, doesn't mean its value can change while the current module is executing. In spec-ese, globals are part of the store and each global has an address that doesn't change. Being imported is really more about which module defines the initial value of the global, but once everything is instantiated, running code assumes that the values in the store are only mutated as specified in the spec. In other words, it assumes that (ignoring threads) other wasm code or host code isn't running concurrently and mutating the store, outside of calls to an import (calls to an import do run code that isn't visible to the current module, so it has to assume imported globals can change across such calls). Switching to an intrinsic can have the same effect if LLVM assumes it has side effects.
What you're asking for is really more like C's volatile keyword, which tries to encompass similar use cases, e.g. access to memory-mapped I/O, communicating with DMA-using devices, and other cases where there are effects that are unmodeled by the language. Wasm doesn't really have anything like that, so replacing your global.gets with import calls to get your addresses is IMO the right approach.

[mf-RDP-two]

Thanks dschuff for taking time.
If there is no general interest in addressing that issue, it can be closed.
I can't do that, unfortunately.