Hi all -- I've just posted blog post 3 of 3 on Cranelift: this one about the regalloc checker: https://cfallin.org/blog/2021/03/15/cranelift-isel-3/
Please feel free to share and/or give feedback and/or ask questions :-)
Is this a hard problem, and if so, why? In fact, it is NP-complete
This reads a bit awkward.
In the "Checking the Register Allocator" section it would be nice to consistently place "machine code" relative to "register allocator" in the diagram.
Nice post!
Thanks! I tweaked the wording there; also added some more detail about lattices, and other bits, from some feedback on Reddit.
lol the footnotes have footnotes :joy:
tweeted it out for you, as usual: https://twitter.com/fitzgen/status/1371872683772628994 :stuck_out_tongue_wink:
Correctness in Register Allocation new blog post by Chris Fallin on the symbolic checker and fuzzing set up we have for Cranelift's regalloc https://cfallin.org/blog/2021/03/15/cranelift-isel-3/
- fitzgen (@fitzgen)Thanks!
I may have been a bit exuberant with the footnotes, but there's just so much interesting stuff to say...
you didn't even touch on the fact that the fuzz inputs are driven by libfuzzer and the arbitrary
crate, which let us get coverage guided fuzzing with structured inputs :-p
it just adds one more layer of niceness onto the whole approach
Oh, yes, the whole "fuzzing is fantastic" discussion could fill a blog post of its own
Nice post! Tbh, register allocators have never been the greatest source of bugs for doing the correctness analysis on for me - that's if you dealt with swaps and the lost copy problems properly. It feels like the meet condition is, "don't allocate the same register twice," which is pretty common-sensical.
I should say, don't allocate two values to the same register if they are live at the same time.
Last updated: Nov 22 2024 at 16:03 UTC