fitzgen edited issue #1065 (assigned to fitzgen):
To write a functional language compiler using this IR, tail call eliminations would be desirable. Are there any plans to support this? I couldn't find any details in the docs.
fitzgen commented on issue #1065:
So @jameysharp and I did a little profiling/investigation of switching the internal Wasm calling convention over to
tail
on our sightglass benchmarks. I was really expecting this to have no measurable change, but unfortunately it looks like it has a ~7% overhead on bz2 and spidermonkey.wasm and ~1% overhead on pulldown-cmark. This is surprising! We think this means that we ~frequently call functions that don't have enough register pressure to clobber all callee-save registers, and sincetail
only has caller-save registers and zero callee-save registers, we are doing more spills than we used to. Enough more that it is really measurable.Supporting caller-save registers with the
tail
calling convention is possible, but requires more work. Either we do parallel moves (and also avoid building the temporary stack frames for tail calls with stack arguments) or we add a bunch of fiddly offset computation for tail calls. Both possible, but I don't want to do either right this very moment. I'd really like to get awasmtime::Config
knob for Wasm tail calls shipping first.So here is our updated plan:
- [ ] Only use
tail
as the Wasm internal calling convention when the Wasm tail calls proposal is enabled. This avoids any impact on existing Wasm programs that don't use tail calls. However, it requires a bit of unfortunate plumbing, but that's fine.- [ ] Finish implementing the Wasm tail calls proposal on all platforms and make sure it is fully spec compliant and all that.
- [ ] Fix the performance issues after that knob is exposed.
- [ ] Switch all Wasm internal calling conventions to
tail
after that.- [ ] ... profit
Additionally, we would not enable tail calls by default in Wasmtime until the performance issues are addressed.
Last updated: Dec 23 2024 at 12:05 UTC