Prevent auto discarding of value names in LLVM IRs #27
Conversation
|
Is it worth instead rolling the fastcomp port for latest llvm ToT? (I'm not sure what the policy is on cherry picking changes like thie vs rolling forward.. @kripken ?) |
|
Looks good, thanks @milizhang! Can you please just add a link to the clang change (say, in the commit message)? @sbc100 updating fastcomp to latest ToT would take more effort, and given plans to switch to the upstream backend soon, probably not worth it, I'd guess? My feeling is that even if it's not that hard to do (which I'm not sure of either way), it would be additional update risk for users for little gain. |
This change adds option to manually control whether to discard value names in LLVM IRs generated by Clang. Upstream change can be viewed at: https://reviews.llvm.org/rC324498
milizhang
force-pushed
the
discard-ir-value-names
branch
from
95079e0 to
06f0802
Compare
|
Done. @kripken If my understanding is correct, the plan seems to be to switch to the WASM target of LLVM/Clang in near future? Just curious whether that will impact the ASM.JS path. |
|
Thanks @milizhang! We plan to switch the default to the upstream LLVM wasm backend, but both backends will be supported for some time, since non-wasm output is something many users want, yeah. In the long term, we may change the details of how we do that (see WebAssembly/binaryen#1929). |
The mozilla build infrastructure is currently down due to a problem with the key not working. We're trying to sort that out, but it's not clear how long that will take (and whether it will happen before we replace those bots anyhow). Meanwhile, no new tags are being built, which blocks PRs like #8263 that need a new fastcomp binary. This PR unblocks them by using fastcomp from the waterfall, which is very up to date. Implications: * We depend on green builds on the chromium waterfall on linux. Those tend to be green pretty often these days. * As a result, we are probably going to be more up to date than usual on fastcomp builds - we won't need to manually tag a version to get a new binary build. So this PR may actually get us to a more convenient state anyhow, and we can just keep it until we get the new builders. Note that this doesn't affect binaryen etc., as the only thing we use from the waterfall on CI is the fastcomp LLVM+clang. PR also contains: * Test updates (funnily, we changed how variable names are emitted by asm.js in emscripten-core/emscripten-fastcomp-clang#27 and actually the backend uses code size to decide some things - so variable names actually matter...) * Remove an old unneeded test for the native optimizer - we don't need to check the EMCC_NATIVE_OPTIMIZER env var any more. (I started to investigate why the test fails with the waterfall build, and it seems like a path issue of some sort, but I doubt it's worth figuring out if we just don't need that test anyhow.)
This change is another part that aims to solve #7883, by adding "-fno-discard-value-names" to clang invocation calls from emcc.py, when debug levels >= 3. It depends on emscripten-core/emscripten-fastcomp-clang#27.
This change is another part that aims to solve emscripten-core#7883, by adding "-fno-discard-value-names" to clang invocation calls from emcc.py, when debug levels >= 3. It depends on emscripten-core/emscripten-fastcomp-clang#27.
This change ports Clang rC324498 to Emscripten, which adds an option to manually control whether to discard value names in LLVM IRs generated by Clang.
This change is the first step toward resolving emscripten-core/emscripten#7883.
Passed random100.