diff --git a/meetings/cranelift/2022/cranelift-01-24.md b/meetings/cranelift/2022/cranelift-01-24.md index 58f7eeed2e..628f0a6961 100644 --- a/meetings/cranelift/2022/cranelift-01-24.md +++ b/meetings/cranelift/2022/cranelift-01-24.md @@ -21,4 +21,116 @@ ### Attendees +* fitzgen +* cfallin +* alex +* alexa +* akirilov +* abrown +* jlbirch +* ulrich +* bnjbvr + ### Notes + +* 2022 roadmap + * cfallin: hope most of you have seen the RFC I authored, with feedback from + many folks + * cfallin: if no one has quibbles, we can probably push it forward and + finalize it as we are 1/12 into 2022 + * ulrich: had a quick one over the other day and it all looks great + * cfallin: okay I will make a motion to merge it +* ISLE coordination + * cfallin: saw the quest issue that fitzgen created the other day + * cfallin: wanted to make sure that everyone was aware of where we are + * fitzgen: planning on working on x64 ISLE at about 50% time + * alex: not working on aarch64 anymore + * cfallin: I can spare some cycles for aarch64 + * ulrich: outstanding ISLE unknown: how to do ABI stuff and calling + conventions the ISLE way + * [missed something about arm32] + * cfallin: idea: platform tiers + * cfallin: similar to Rust and its tier 1/2/3 + * cfallin: top tier: guaranteed to compile, pass tests, have CI, and all + that. lower tier: guaranteed to compile. even lower tier: allow compilation + failures + * cfallin: the alternative to the last tier is just remove the WIP arm32 + backend, we don't want it to slow us down + * akirilov: ARM position is to focus on 64-bit, at least for + Wasmtime/Cranelift, doubt that any ARM engineers will work on this, ARM is + in the process of removing 32-bit support from CPUs entirely + * fitzgen: is it even worth having this code in tree if we don't even check + that it compiles? + * ulrich: GCC has a policy that every platform has to have an active + maintainer who is responsible for fixing things when there are breaking + changes that affect every platform, if they are MIA then the steering + committee holds a meeting and decides what to do (potentially removing the + platform support from GCC) + * fitzgen: I like that approach, we can do something like that + * ulrich: yes, just have to ping the platform maintainer first, rather than + just delete it immediately + * abrown: every week, I see one or two issues about "is X supported?" we + should have some documentation about platform support +* ISLE support for calls and ABI code + * ulrich: ABI/calling convention code is a bit special, it isn't SSA-y + * ulrich: impossible to use slices of values without borrow check errors + * cfallin: fitzgen and I talked a little about this, splitting immutable and + mutable contexts + * fitzgen: issues with splitting if we don't want to re-engineer non-ISLE data + structures + * ulrich: can avoid slices by using `ValueList` instead of `ValueSlice` + * ulrich: for each argument, call `AbiCaller` impl stuff, do sign extending or + whatever and all that, then back into target code for generating moves into + specific registers and all that, all this is incompatible with ISLE, because + it has its own buffer of to-be-emitted instructions. this will get screwed + up because ISLE won't be able to rename registers for the stuff emitted by + platform agnostic code. + * cfallin: would make sense to move that stuff into ISLE just to simplify the + moving parts here, have not just `lower` but also `lower_call` and + `lower_prologue` and `lower_epilogue`. when playing with SSA mach insts for + initial regalloc2 experiments, had one macro instruction for these things + * fitzgen: were these macro instructions doing SSA-y things like "new_sp = + bump old_sp"? and then ensuring that only one sp is live at any time? + * cfallin: no, just single instructions that did whole prologue/epilogue. + * cfallin: creating new ISLE that is platform independent would be our first + platform-independent ISLE + * ulrich: just have an `extern constructor` in ISLE that calls this ABI stuff + and emits into ISLE rather than the existing lower context. not very + ISLE-like. could maybe have some shared code similar to `prelude.isle`? + * fitzgen: could implement a shared `abi.isle` that relies upon certain + symbols being defined by platform, but if you have those implemented, then + everything Just Works +* status updates: + * jlbirch: wrote some skeleton code for a sightglass benchmarking server, + still working on the workflow, just wanted to let people know that this is + being actively worked on + * fitzgen: more ISLE x64 porting. adding newtypes for GPRs vs XMMs. + * cfallin: been adding new approaches to cooperative interruption in Wasmtime + that are faster than fuel, uses cranelift, but doesn't really affect + cranelift + * ulrich: big update is the ISLE migration, thanks for reviews. just need + branches, traps, calls, and returns are still needed. working on traps right + now. smaller issues: need to add safepoints support for some traps. fixing a + bug in the `clif.isle` compile-time generator. branches need to know their + targets when they are lowered. not sure how to get this info inside of + ISLE. added a context callback to make it work for now, but its a bit ugly. + * fitzgen: extern extractor to grab branch target for a branch instruction? + * cfallin: a new entry point into ISLE that is `lower_branch` and has extra + arguments? call this rather than regular `lower` when lowering branch + instructions? + * alexa: just starting an SMT-based interpreter for ISLE rules, no concrete + results yet. + * abrown: been working on migrating `select` to ISLE + * akirilov: no updates, but Fredd(y|ie)? is another ARM engineer who is going + to join the ISLE aarch64 porting efforts. going to start with atomics and + SIMD instructions. can coordinate on the ISLE quest issue. + * alex: a question: would it make sense to start trying to port s390x to + regalloc2 as a learning experience for other backends? + * cfallin: there is so much shared code it is basically impossible to do one + backend at a time. putting this off until we are closer to finishing the + ISLE migration, and don't have to be so speculative. + * ulrich: in general ISLE has been very nice and will make adding new + lowerings much easier. but have also found a couple issues. ISLE code that + compiles okay but the generated Rust won't compile. working with immediates + was a little tedious as well, because you end up writing trivial + constructors for things like addition.