[WebAssembly] add ability to intialize `global`s

[daxpedda]

Its currently not possible to define Wasm globals with a non-default value.
E.g.:

.globaltype foo, i32, immutable

produces:

global i32 i32.const 0

Unfortunately simply adding a parameter to .globaltype wouldn't be enough because in reality Wasm potentially supports a whole instruction sequence here.

Instead I would propose the following:

.globaltype foo, i32, immutable
.globalinit foo
  i32.const -1
end_function // or some other more appropriate directive

would produce:

global i32 i32.const -1

Happy to do the implementation on a design sign-off.

Pinging @sbc100 as a target maintainer.

[sbc100]

While this would certainly be nice to have I imagine it would be fair amount of work. It would also only benefit folks who hand-write assembly, which is a small number.

Would doing the more limited thing of only supporting a single number be enough for you use case or do you need support for extended const expressions which allow more instruction sequences.

[llvmbot]

@llvm/issue-subscribers-backend-webassembly

Author: None (daxpedda)

Details

Its currently not possible to define Wasm `global`s with a non-default value. E.g.: ```gas .globaltype foo, i32, immutable ``` produces: ```wat global i32 i32.const 0 ```

Unfortunately simply adding a parameter to .globaltype wouldn't be enough because in reality Wasm potentially supports a whole instruction sequence here.

Instead I would propose the following:

.globaltype foo, i32, immutable
.globalinit foo
  i32.const -1
end_function // or some other more appropriate directive

would produce:

global i32 i32.const -1

Happy to do the implementation on a design sign-off.

Pinging @sbc100 as a target maintainer.

[sbc100]

i.e. could we just support non-extended const expression? e.g. .globalinit foo 0?

Also, if we want to support the full instruction thing, maybe we should use foo: to declare the body, just like we do for function and data symbols?

[sbc100]

Indeed you already need to do foo: to actually declare a global (declaring its .globaltype is not enough).

[daxpedda]

Would doing the more limited thing of only supporting a single number be enough for you use case or do you need support for extended const expressions which allow more instruction sequences.

A single number would be enough for our use case.

Though I am also thinking of rust-lang/rust#136382 and further discussions in WebAssembly/wabt#2649. If Rust really ends up implementing a WAT to S converter, full support for various Wasm operations in the S-format would be necessary.

[sbc100]

Would doing the more limited thing of only supporting a single number be enough for you use case or do you need support for extended const expressions which allow more instruction sequences.

A single number would be enough for our use case.

Give that we already implement globals with a label (.e.g foo:) I guess a new .globalinit is not actually that way to do.
So perhaps parsing instructions after foo: does actually make sense. It could just be single instruction initially. If you would like to take a stab at that I'd be interested to see how complicated that would be.

Though I am also thinking of rust-lang/rust#136382 and further discussions in WebAssembly/wabt#2649. If Rust really ends up implementing a WAT to S converter, full support for various Wasm operations in the S-format would be necessary.

I'm not sure that strictly true is it. I won't using WAT for inline assembly would mean 100% of WAT constructs would be guaranteed to work. A functional subset would be work too, no?

[daxpedda]

Would doing the more limited thing of only supporting a single number be enough for you use case or do you need support for extended const expressions which allow more instruction sequences.

A single number would be enough for our use case.

Give that we already implement globals with a label (.e.g foo:) I guess a new .globalinit is not actually that way to do. So perhaps parsing instructions after foo: does actually make sense. It could just be single instruction initially. If you would like to take a stab at that I'd be interested to see how complicated that would be.

So the instruction would just come after .globaltype or doesn't it matter as long as its after the label?
Will give it a try!

Though I am also thinking of rust-lang/rust#136382 and further discussions in WebAssembly/wabt#2649. If Rust really ends up implementing a WAT to S converter, full support for various Wasm operations in the S-format would be necessary.

I'm not sure that strictly true is it. I won't using WAT for inline assembly would mean 100% of WAT constructs would be guaranteed to work. A functional subset would be work too, no?

Yes absolutely. What I should have said is that its necessary that at least the possibility of covering any Wasm operation must be present, otherwise a possible need in Rust would be blocked.

[sbc100]

Yes absolutely. What I should have said is that its necessary that at least the possibility of covering any Wasm operation must be present, otherwise a possible need in Rust would be blocked.

But what are "any Wasm operation must be present". The .s format today can handle all the operations that C/C++ assembly authors have needed so far. i.e. the initialization of wasm globals to non-zero values has not come up as an urgent need thus far in the C/C++ world. Do you have reason to believe that authors of rust inline asm will have different requirements?

Don't get me wrong, I can see that it is a useful thing.

[sbc100]

So the instruction would just come after .globaltype or doesn't it matter as long as its after the label?
Will give it a try!

The instruction would come directly after the label.

I assume the .globaltype would need to precede the label (although not directly necessarily) so that the assembly knew it was parsing a global and not a function.

[daxpedda]

But what are "any Wasm operation must be present".

Sorry, I meant to say:
"the possibility [..] must be present". Not that every operation must be present.
My English isn't the yellow from the egg.

No, I don't believe requirements will differ to C/C++.

So the instruction would just come after .globaltype or doesn't it matter as long as its after the label?
Will give it a try!

The instruction would come directly after the label.

I assume the .globaltype would need to precede the label (although not directly necessarily) so that the assembly knew it was parsing a global and not a function.

I see, I was actually putting the .globaltype after the label hence the confusion.
(note: this worked just fine as well)