Merge pull request #3171 from bytecodealliance/fitzgen-patch-1

Add notes for 2021-08-09 Cranelift meeting

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