Derek Schuff

Ah, so here is where we have to decide how general-purpose we want the pass to be. If this is just for lowering away LLVM-produced memcpy and supporting older browsers,...

Ah, good point about the order. LLVM does lower both to memory.copy (see WebAssemblySelectionDAGInfo.cpp). Yeah, my way of testing was just to run the passes unconditionally and send them through...

> Btw, an issue I realized with limiting these passes to LLVM's output is that we can't run the spec tests on them or fuzz them, not normally at least....

Sorry, I was thinking of the comments above about possible overflow when checking for out of bounds trapping. Currently we don't handle that because UB, but if we wanted to...

Yeah my thinking was that extending to i64 would be simpler than adding the extra condition you mentioned for both src and dst. But I'm also leaning toward not bothering...

OK, assuming we keep the current trapping behavior, and the current structure (i.e. of generating rather than merging the polyfill functions) I think this is ready.

> I like the idea to add an MVP test mode. Off on CircleCI, just running on the testsuite bot? Yeah, along with the ASan and similar modes.

> I think we could add some execution tests for this, under `test/lit/exec/`. The tests can contain some copy/fill operations, and print memory contents after the operation. By running them...

Thanks, WDYT of the memory copy test? It's derived from the wast spectest but turned into a fuzz-exec test.

Looks like this test still timed out on wasm64 (https://app.circleci.com/pipelines/github/emscripten-core/emscripten/28241/workflows/3ee98437-344e-43ec-aa8f-d5212a626ffe/jobs/641185). i'll retry to see if it's flake or consistent.