sunfish added a comment. In D70500#1999268 <https://reviews.llvm.org/D70500#1999268>, @bernhard wrote:
> > It's for users who want smaller wasm binaries. It's not currently > > documented, though yes, it would be nice to document it. > > But how would a user even end up with wasm-opt in the same directory of clang > binaries? wasi-sdk may package wasm-opt that way in the future. But, wasm-opt can also be found in the PATH. >> 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. > > I'm generating additional data segments which while doing so increases the > initial memory pages count and shifts any globals that point to __heap_base > and global[0] (stack ptr init). Would it work to increase the memory size, and then put your data in the new space this creates at the end of memory? This would avoid the need to shift anything around or depend on anything about the layout. It isn't yet documented anywhere, but the pattern of always allocating new memory at the end of the address space (as `memory.grow` does) is common enough and important enough that we probably should document it. > Due to memory-packing the end of data becomes ambiguous (-export=__data_end > would mitigate that but it's nice to be compatible with any un-opt'ed wasm > file), and due to simplify-globals with remove-unused-module-elements the > global[0] can get copied/moved directly into the code section. > I am aware that this treads very much in undocumented assumptions, it is > still experimental but it works. This hidden execution of wasm-opt is mostly > making documentation on my end a bit harder. `__data_end` and `__heap_base` aren't things you can move around once the linker has defined them. Their values can be baked in elsewhere in the wasm module, so it's not safe in general to insert new memory in between them and shift things around. And it happens that wasi-libc has some code that we hope to enable soon which allocates malloc memory using `__heap_base` which would likely break if things get shifted around after linking. 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
