Feature suggestion (memcpy/memset)

[lskyum]

First of all - sorry if I missed it in the spec!

The suggestion is for simple memcpy/memset instructions, so copying/clearing can be done at maximum speed for any given platform/browser. For example bounds-checking doesn't have to be done pr. read/write, but only once. (Could be an issue on some implementations I think. Maybe also the polyfill...)

The memcpy could be provided in two versions, one that checks for overlaps and one that doesn't.

[cristiano-belloni]

Aren't memcpy / memset / memmove usually implemented at an higher level, ie in the C stdlib? Example implememtation in XNU: http://www.opensource.apple.com/source/xnu/xnu-2050.18.24/libsyscall/wrappers/memcpy.c

[waywardmonkeys]

In emscripten, memset and memcpy can result in pretty bloaty code, especially when compared to native code and what a loop expands into. (We suffer a good bit from things related to this in our code base that is compiled with emscripten.) I don't know how that would be in WebAssembly or if it would be less bloaty.

[MikeHolman]

Interesting thought.

You might be able to rely on the wasm engine recognizing this pattern and optimizing the loop/removing bound checks (our engine is starting to do some optimizations when it recognizes the "memcpy" pattern in js). And when we have SIMD support we can implement memcpy pretty efficiently in wasm without as much reliance on optimizations from the wasm engine. To this end, it would be interesting to see how much SIMD helps memcpy in asm.js.

I think this should be less bloated in wasm (even in asm.js I think we could probably just not inline memcpy and clear up the code bloat -- I'd think in most cases inlining them won't really improve perf because call overhead would be dwarfed by the actual copy).

But it might be worth considering because it could help perf for baseline compiler (which might not have BCE), and it could reduce AST size (obviously important).

[waywardmonkeys]

@MikeHolman The issue with not inlining in emscripten is that various patterns of code get converted to llvm.memcpy* and llvm.memset* calls ... this happens in constructors and other locations, as well as (sometimes) LLVM looking at a loop and deciding it can be converted to one of these calls.

[sunfishcode]

WebAssembly does have fewer pain points than asm.js in this area, but there would still be advantages to adding these.

For memcpy, as opposed to memmove, it's not clear that introducing nondeterminism for the operlapping case is worth the minor performance difference, and we can always add it in the future if we wish.

[jfbastien]

Agreed on adding memset and memmove intrinsics:

• Different architectures want different code (even different x86 CPUs want something different), and I'm comfortable letting the developer-side compiler (e.g. LLVM) peephole. Having the WebAssembly compiler detect these patterns isn't something I'd advise for now.
• Agreed with @sunfishcode that memcpy could be added after memmove if data shows we need it.

How should we define intrinsics in WebAssembly is the next question. Unresolved external functions with a special name? That's getting dangerously close to having some limited ABI, but I'm OK in this case.

[lskyum]

An improvement to the idea could be memcpy4/memcpy8/memcpy16 that only allows a multiple of 4/8/16 bytes to be copied, so some checks could be skipped. For example when using SIMD instructions for copying.

[sunfishcode]

@jfbastien If we add new builtin operations, we should just add them as plain AST node kinds. I don't think we need an instruction/intrinsic distinction as LLVM has.

@lskyum I agree that some provision for copying with known size multiples, and known alignments too for that matter, is worth considering.

[jfbastien]

@sunfishcode AST nodes sound good.

On known size / alignment: what's the behavior when the code was incorrect? Force realign+overcopy, trap, implementation defined?

[sunfishcode]

For the size multiples, one possibility would be to have a scale operand, possibly required to be a literal, that the size operand would be implicitly shifted by. For alignment, perhaps we could just do what load+store do and say "it's really slow" if the given alignment is wrong.

[titzer]

I think memmove would be OK, but I would prefer not to have many variants
for different sizes and different alignment cases. The primitive of "copy
these many bytes from here to here" is plenty expressive, and the engine
should do optimizations when it detects either statically or dynamically
that an optimized implementation would be better.

On Mon, Jun 29, 2015 at 7:26 PM, Dan Gohman notifications@github.com
wrote:

For the size multiples, one possibility would be to have a scale operand,
possibly required to be a literal, that the size operand would be
implicitly shifted by. For alignment, perhaps we could just do what
load+store do and say "it's really slow" if the given alignment is wrong.

—
Reply to this email directly or view it on GitHub
#236 (comment).

[lskyum]

Just so it won't be forgotten. A memset (or memclear) would be usefull for implementing a C#/Java VM because all objects and arrays are initialized to 0/null on creation.

[sunfishcode]

I am contemplating a proposal as follows:

  int32 memmove32(int32 dst, int32 src, int32 size);
  int32 memzero32(int32 dst, int32 size);

Semantics are hopefully obvious :-). With >4GiB heaps, 64-bit versions would be added too. I'm now leaning away from size/alignment hints for now because I don't think they're the most critical, and there's value in starting simple. Return value is the value of dst, and is there because it allows greater expression tree formation. Comments?