Optimize some std mem methods by replacing expensive rem operations to fast bit logic

[MaxGraey]

No description provided.

[dcodeIO]

Seems like a good issue for Binaryen's optimizer as well.

[MaxGraey]

Yep, I thought about it as well

[MaxGraey]

And what you think if replace this:

    store<u32>(dest     , load<u32>(src     ));
    store<u32>(dest +  4, load<u32>(src +  4));
    store<u32>(dest +  8, load<u32>(src +  8));
    store<u32>(dest + 12, load<u32>(src + 12));
    src += 16; dest += 16; n -= 16;
    src += 16; dest += 16; n -= 16;

to:

    store<u64>(dest     , load<u64>(src     ));
    store<u64>(dest +  8, load<u64>(src +  8));
    src += 16; dest += 16; n -= 16;
    src += 16; dest += 16; n -= 16;

for aligned memory copy?

[dcodeIO]

Depends whether dest and src are guaranteed to be aligned to 8 bytes at this point.

[dcodeIO]

Seems not, as it starts with if (dest % 4 == 0)

[MaxGraey]

You are right. But for classes and arrays we can expecting 8 byte alignment when mem layout will be finish of course, right? So It's exactly for that case (dest % 8 == 0) and It seems this additional part, not replacment

[dcodeIO]

Well, imagine an Uint8Array. The class would be aligned to 4 bytes because it starts with an i32 length (unless WASM64 is the target, requireing a pointer to the array being aligned to 8 bytes). Its data, which is a separate block, would be aligned to 4 bytes just because that's the minimum alignment (otherwise it'd be 1).

Don't worry too much about these. The copy_memory and move_memory stuff will be replaced by bulk memory operations anyway, once these have landed.

[MaxGraey]

Ok, I got it

[dcodeIO]

These changes are looking good to me. Please include yourself in the NOTICE file before I merge :)

[MaxGraey]

Done! Thanks;)

[dcodeIO]

Thanks :)