sunfish added a comment. In D70500#1998994 <https://reviews.llvm.org/D70500#1998994>, @bernhard wrote:
> Are there plans to offer a way to disable this behavior (or have it optional > in the first place)? > We'd like to run some custom processing between wasm-ld and wasm-opt which > can't happen after the latter due to some of its one-way destructive > optimizations (i.e. memory-packing or simplify-globals passes). > The only way now is to tell our users to place wasm-opt somewhere where > clang can't find it. Or instead of using one clang super-command to manually > call -cc1 and wasm-ld separately which is disappointing. > > Also, is it even common to place wasm-opt next to the clang executable? Who > is this for? Is this documented? It's for users who want smaller wasm binaries. It's not currently documented, though yes, it would be nice to document it. That said, details about how LLVM lays out memory or uses globals are intentionally not documented. Just as we don't make any guarantees about exactly which optimizations we do at -O1 vs -O2, we're don't make any guarantees about which optimizations are done in clang vs wasm-ld vs wasm-opt. Clang and wasm-ld are free to do anything wasm-opt does. Could you describe what you want to do in more detail? It may be possible to find alternative approaches, or to design a feature for it with a clear and documentable scope. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D70500/new/ https://reviews.llvm.org/D70500 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
