cranelift: Don't recompute allocatable register set #8457
Conversation
The implementation of `PRegSet::from(self.vcode.machine_env())` does a surprising amount of work: it lazily initializes a `OnceLock` in the backend, then loops over six vectors of registers and adds them all to the `PRegSet`. We could likely implement that better, but in the meantime at least we can avoid repeating that work for every single machine instruction. The `PRegSet` itself only takes a few words to store so it's cheap to just keep it around. I discovered this because when the call to `self.vcode.machine_env()` is in the middle of the loop, that prevents holding a mutable borrow on parts of `self.vcode`, which I want to be able to do in another PR.
github-actions
bot
added
cranelift
|
This one really surprised me so I went looking at history to figure out if we ever measured it: it looks like first appeared in #6957; previously the Out of curiosity have you seen a perf improvement with this PR? (We should do it even if not, but it seems to me it should improve compile time) |
cfallin
left a comment
cfallin
left a comment
There was a problem hiding this comment.
also I'll go ahead and r+ since I dug into this (sorry to preempt reviewers!).
|
According to hyperfine, this commit is 1.02 ± 0.01 times faster when running |
2 participants
The implementation of
PRegSet::from(self.vcode.machine_env())does a surprising amount of work: it lazily initializes aOnceLockin the backend, then loops over six vectors of registers and adds them all to thePRegSet.We could likely implement that better, but in the meantime at least we can avoid repeating that work for every single machine instruction. The
PRegSetitself only takes a few words to store so it's cheap to just keep it around.I discovered this because when the call to
self.vcode.machine_env()is in the middle of the loop, that prevents holding a mutable borrow on parts ofself.vcode, which I want to be able to do in another PR.