Expose wasm instrinsics for grow_memory and current_memory instructions

[fitzgen]

I've wanted to use these instructions, but no way to access it, and can't write WAT by hand either because of #22

[pepyakin]

Actually you can access some intrinsics, see for example

[fitzgen]

Will that #[link_name] always work? Is it stable in the Rust sense? Those comments mention how llvm doesn't currently expose the return value from grow_memory but eventually will -- will my code break when that transition happens?

[alexcrichton]

@fitzgen nah that's an unstable (permanently) feature, we'd want to look to exposing these intrinsics elsewhere rather than using the example there. That's just what's needed to implement it in libstd today.

[koute]

If you want to use it on stable Rust right now and be sure your code won't break in the future you could add an extern { fn grow_memory(pages: u32); } in your code, and then postprocess the .wasm file and replace that import with an actual function which would call the grow_memory instruction for you.

Of course having this actually exposed by Rust as an intrinsic would be a lot better.

[fitzgen]

Yeah. Or if we had a working linker, I could define out-of-line functions in WAT, compile them to .wasm in build.rs (or just check in the .wasm to the crate repo), and then link against that .wasm file.

Neither seems ideal, although linking doesn't seem too terrible.

I think we should have proper intrinsics, though. How would we go about adding and stabilizing them?

[pepyakin]

I bet that this is far away from stable, instrinsics could get new immediate(s) and I think there is a high chance that the code will break after the transition.

(oops, seems im loo late)

[sunfishcode]

FYI, grow_memory and current_memory are likely to be renamed in the wasm spec to mem.grow and mem.size; see WebAssembly/spec#627.

I'm expecting to introduce new intrinsics in LLVM (and new builtins in clang) with the new names soon (and they'll probably have an operand for the wasm immediate too).

[alexcrichton]

Thanks for the heads up @sunfishcode!

My thinking for how we'd expose this in Rust is probably to add it to the stdsimd crate. That crate's moreso "vendor intrinsics" rather than just SIMD stuff. Currently it's not integrated into libcore but hopefully that'll happen in the somewhat near future!

[sunfishcode]

The wasm CG is moving forward with the rename, though the decision is not fully final yet.

I've tentatively added intrinsics with the proposed names in LLVM, along with immediate operands, here.

[alexcrichton]

@sunfishcode so right now libstd in Rust isn't great about exposing vendor-specific (platform-specific) intrinsics like SIMD on x86, but that's hopefully changing soon! For things on x86 we've been using Intel's intrinsic guide as a reference point for what the signatures should look like in Rust. In essence we're hoping there's vendor definitions of what we should be doing so there's an obvious path to stabilization for us.

With that in mind, is there something similar for wasm? In other words, is there an 'official definition' of sorts for how these intrinsics should be exposed with a C-like signature? If not no worries, we can always tweak it as it's a nightly target anyway :)

[sunfishcode]

In clang, they now look like this:

    size_t __builtin_wasm_mem_size(int32_t imm);
    size_t __builtin_wasm_mem_grow(int32_t imm, size_t delta);

where the imm argument is required to be a compile-time constant.

There's no official documentation for these yet, but I expect that these are what will eventually be documented. Provided that the CG doesn't reverse course on the rename.

[alexcrichton]

Ok thanks!

We unfortunately don't have a great way of specifying "this argument must be constant" in Rust right now...

[Diggsey]

You could use an intrinsic with an attribute on I guess, but really you want const generics.

[fitzgen]

@sunfishcode, why do these return size_t? The copy of the standard I've printed out says that these intrinsics return an i32 and use -1 to signal an error. How would I check for an error with the size_t signatures? Additionally, grow_memory expects an i32 delta, which implies to me that one could use negative numbers to shrink memory and return space to the engine.

the imm argument is required to be a compile-time constant.

This seems unfortunate. Are we supposed to call this intrinsic in a loop until we have grown memory to its desired dynamic size? What is the motivation for this restriction?

[pepyakin]

@fitzgen isn't size_t is always 32-bit integer in wasm32?

And yes, you can't shrink memory with grow_memory. In fact, you can't shrink memory at all

I guess, imm is constant time expression is beacuse it is supposed to be used for things like memory index, etc