Poor compile performance for wasm32-unknown-unknown compared to x86-gnu-pc

[ttrenner]

Compiling the attached source file (s. tar-ball) to wasm32, with debug information switched on, takes significantly more time than doing the same for a x86-gnu-linux-pc target.

Extracting the attached zip, you'll see a README.md plus a flamegraph, that makes the WebAssemblyDebugManager looking suspicious. It seems that it scales w/ O(n^2) where n is the amount of (generated) stackvariables/statements/subexpressions.

At first sight, we are interested, whether this is a general issue (e.g. due to wasm32's stackmachine model or due to the way of how clang/llvm generates debug information) or whether it can be fixed w/o super-heavy refactorings because it is just an inefficient implemention of clang/llvm.
In the latter case, it would be great if someone can have a look at it.

[llvmbot]

@llvm/issue-subscribers-backend-webassembly

Author: Thomas Trenner (ttrenner)

Compiling the attached source file (s. tar-ball) to wasm32, with debug information switched on, takes _significantly_ more time than doing the same for a x86-gnu-linux-pc target.

Extracting the attached zip, you'll see a README.md plus a flamegraph, that makes the WebAssemblyDebugManager looking suspicious. It seems that it scales w/ O(n^2) where n is the amount of (generated) stackvariables/statements/subexpressions.

At first sight, we are interested, whether this is a general issue (e.g. due to wasm32's stackmachine model or due to the way of how clang/llvm generates debug information) or whether it can be fixed w/o super-heavy refactorings because it is just an inefficient implemention of clang/llvm.
In the latter case, it would be great if someone can have a look at it.