Add instrument allocations pass

[loganek]

This pass wraps malloc/calloc/free/realloc around trace_{func_name} functions so we can keep track on all the allocations. I understand this pass won't work for some of the languages, but opening a PR in case someone finds it useful and worth enough including in wasm-opt.
Also, I don't have a ton of experience writing compiler passes, so any suggestion is very appreciated.

Related issue: #6548

[kripken]

Another option rather than instrumenting around each function call is to add new wrapper functions. That would be better for code size (existing calls remain the same size, they just point to the wrappers, and the wrappers are just a fixed increase in size). The inliner can inline them if the user then optimizes (and the inliner thinks it is worth it), which could make it just as fast.

But if size/speed are not important here then the current approach may be fine.

[loganek]

I personally only intend to use it for debugging and not in the production code (at at least so far) so neither speed nor size is critical. I think the pass can be updated once there are different usecases.

[kripken]

Is there an explanation of the commandline format somewhere? If it's short enough in the --help that would be good, but I think it might not be, so the .cpp file perhaps.

However, a second question: Why does the commandline format have the types in there? It seems like we can detect the types from the function name? But I may have forgotten something here.

[loganek]

Is there an explanation of the commandline format somewhere? If it's short enough in the --help that would be good, but I think it might not be, so the .cpp file perhaps.

With the latest update where I removed the need for specifying the types, I think it's simple enough; there was already a help string defined in the TraceCalls.cpp in the getArgument() - it's not printed on --help, but it's displayed when the user tries to incorrectly use the pass. Do you think this should also be displayed when user calls --help? I'm not sure I saw it for other passes (e.g. extract-function-index).

However, a second question: Why does the commandline format have the types in there? It seems like we can detect the types from the function name? But I may have forgotten something here.

That's an excelent point; so initially the tracer was for pre-defined functions (malloc,calloc, realloc, free) but I changed that after the suggestion in the comment #6619 (comment) to make the pass more generic; I also blindly followed the recommendation to include types as parameters but it actually is not needed, and we can infer the type from the function being traced. I updated the PR now, thanks.

[kripken]

Looks much better!

[kripken]

Looks like there are some CI errors that need to be resolved before landing (edit: i see there was a force-push since, let's see if that fixes things edit edit: still some errors it seems)

[loganek]

@kripken the build is fixed now. Tests were failing because I iterated through unordered_map to create imports which is non-deterministic; I switched to map which doesn't make significant difference in this specific case, but I'm curious how do you normally deal with this type of nondeterminism when you write LIT tests?

[kripken]

@loganek Iterating on a map here makes sense, yeah, as the keys are Names. In general we sometimes fix nondeterminism that way, if there is a natural key to use. If there aren't, say if the map is from Expression*, then we need something else (since pointers change in every execution), and then we have to find another way. One mechanism is InsertOrderedSet which uses the insertion order to be deterministic (assuming that order in fact is).