5.7 KiB
5.7 KiB
August 9 Cranelift project call
See the instructions for details on how to attend
Agenda
- cfallin: instruction selection pre-RFC
- cfallin: update on RA2 (review in progress; licensing)
- jlbirch: Simd fuzzbugs ... following a consistent set of standards when lowering.
- General status updates
Attendees
- Nick Fitzgerald (nf)
- Chris Fallin (cf)
- Andrew Brown (abrown)
- Johnny Birch (jb)
- Afonso Bordado (abordado)
- bjorn3 (b3)
- Benjamin Bouvier (bb)
Notes
- (cf) instruction selection pre-RFC
- things have gotten complicated enough that a DSL would be nice
- "why will this be different from the old DSL we used to have?"
- learned things, passed a complexity boundary
- would love your comments and discussion on the pre-RFC!
- (abrown) read the pre-RFC, it was good, not convinced that we couldn't just
add some abstractions to the existing hand-written backend without going
full DSL
- fwiw, felt the same way about the original old backend, so maybe just biased towards fixing existing stuff
- mostly concerned with easily understanding what is going on
- depends on what the DSL looks like
- (cf) does it depend on the DSL semantics? if it is really clear what the DSL
maps down to thats better?
- (abrown) the more clear the better
- (bb) also interested in refactorings for the existing backend and how far
that can take us
- with the old backend, we needed better error messages in the DSL and a debugger for the DSL, etc
- building that is a lot of work
- (abrown) wouldn't mind keeping generated code in-tree if we go DSL route
- don't have to search for the proper cargo out directory to inspect generated code
- (cf) interesting. the idiomatic rust approach would be to generate in build.rs
- (abrown) didn't peepmatic keep generated stuff in tree?
- (nf) yes, but mostly so that everyone building cranelift and not touching peepmatic doesn't have to have z3, and anything we start new shouldn't depend on z3, so it should be a non-issue
- (b3) rust-analyzer keeps everything in tree
- (cf) prototyping one design point in this space, lots of open details, trying to make sense of it myself, will share once it is more formed
- (b3) the DSL should be optional
- (cf) the existing APIs should be kept, need a gradual transition, see the horizontal and vertical integration stuff in the pre-RFC
- (cf) update on regalloc2
- being reviewed by Julian Seward from Mozilla and Amanieu from the Rust Project
- Looking to relicense from MPL to Apache + LLVM extension
- Some code derived from SpiderMonkey's regalloc, which is MPL
- Trying to align with other bytecode alliance projects
- (jb) more SIMD fuzz bugs coming in
- should we have some sort of criteria/guidance for approaches to lowering?
- when to use assertions?
- when to use move helper functions vs emit a particular instruction directly?
- mostly want consistency across the code base
- (cf) we should document what invariants we already have, eg:
- invariants regalloc.rs expects
- sinking loads/stores into other ops
- status updates:
- (bb): none
- (abrown):
- working on wasm spec interpreter fuzzing PR
- (abordado):
- fuzzing clif
- adding heap support to filetest infra
- making sure we don't access invalid memory in the clif interpreter
- starting with stack memory
- types of accesses that need to be checked:
- stack
- heap
- tables
- globals
- (nf): none
- (b3):
- waiting on a review for https://github.com/rust-lang/rust/pull/81746
- (jb): none
- (cf):
- pre-RFC and prototype about one point in the design space to learn more
- regalloc2
- thinking about verification in Cranelift
- thinking that it may make more sense to do end-to-end verification, similar to VeriWasm
- carry symbolic info from wasm through to generated code? similar to a recent ASPLOS paper
- thinking that this is easier and more trustworthy than verifying particular lowerings
- (abrown) we can probably make this easier if we kill some old cranelift opcodes, since we are moving towards pattern matching to combine instructions in the lowerings
- (bb) we already have two IRs and if we introduce a DSL we have three languages. is this making it harder to verify? also are we still trying to push vcode up and replace clif?
- (cf) replacing clif is not a big priority
- (b3) vcode not amenable to optimizations that we do on clif
- (abrown) does cg_clif use all of clif opcodes?
- (abordado) doesn't use booleans larger than b1
- (nf) if we do end-to-end verification doesn't matter too much that we have muiltiple IRs and languages, since we are essentially just looking at the final output, but if we are verifying individual lowerings/peephole optimizations, then it matters a lot
- (cf) similar to unit testing vs integration testing
- (abordado) more questions about checking memory accesses in the clif
interpreter
- using native memory+addresses vs indirect tables/maps in the interpreter
- (nf) using tables/maps in interpreter is obviously correct because everything is bounds checked through rust, using native memory+addresses is a bit more a whack-a-mole scenario
- (cf) sort of like allow-list vs deny-list
- (abrown) I like tables/maps in interpreter but don't want to slow down any PRs
- (cf) we want this to be deterministic for replaying fuzz failures, this is a little harder with native memory and different architectures
- (abordado) will prototype something