diff --git a/meetings/cranelift/2021/cranelift-08-09.md b/meetings/cranelift/2021/cranelift-08-09.md index 623853232c..ff4e11a0d9 100644 --- a/meetings/cranelift/2021/cranelift-08-09.md +++ b/meetings/cranelift/2021/cranelift-08-09.md @@ -10,6 +10,117 @@ ## 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