Bongjun Jang (Dec 30 2024 at 09:04): Bongjun Jang (Dec 30 2024 at 09:04):Hi, I'm interested in discovering missing optimization opportunities in cranelift.
I've tried to add/erase some optimization rules in cranelift/codegen/src/opts,
but it does not seem to change the compilation result of my program.
Is there any established way to test a new optimization?
Thank you.
Bongjun Jang (Dec 30 2024 at 09:48):My current workflow is as follows:
emcc example.c to get a wasm module. For example, it contains int y = x / 1 to see that optimization happens.wasmtime explore example.wasm to see the compilation process.I observe int y = x / 1 is not optimized away. But the default optimization level is 2 in wasmtime explore, which is the highest level.
I think it is weird that cranelift misses such easy optimization opportunity in such optimization level.
(Also the optimization is indeed defined in cranelift/codegen/src/opts.)
I'd appreciate if anyone can spot a problem in my workflow.
Chris Fallin (Dec 30 2024 at 17:06):@Bongjun Jang nothing wrong with your experiment -- indeed, we can't optimize away divides right now. This is a limitation in our optimization framework where we can't reason about trapping opcodes -- see https://github.com/bytecodealliance/wasmtime/issues/5908. (In this case of course with a constant nonzero divisor, we should be able to know that no trap will ever occur, and remove the op -- but we don't have the framework to remove any trapping opcode at the moment.)
Chris Fallin (Dec 30 2024 at 17:08):Handling trapping opcodes in our value-based design is not really that "easy", which is why it hasn't been tackled yet; we have plenty of ideas, we just need to take the time to implement them. Once we have the framework, it will then indeed be easy to add rules for specific cases like this
Last updated: Jan 24 2025 at 00:11 UTC