Remove meetings agendas/minutes (moved to separate repo). (#4388)
This PR removes all minutes and agendas in `meetings/`. These were previously hosted in this repository, but we found that it makes things somewhat more complex with respect to CI configuration and merge permissions to have both small, CI-less changes to the text in `meetings/` as well as changes to everything else in one repository. The minutes and agendas have been split out into the repository at https://github.com/bytecodealliance/meetings/, with all history preserved. Future agenda additions and minutes contributions should go there as PRs. Finally, this PR adds a small note to our "Contributing" doc to note the existence of the meetings and invite folks to ask to join if interested.
This commit is contained in:
Chris Fallin
4
.github/workflows/main.yml
vendored
4
.github/workflows/main.yml
vendored
@@ -3,12 +3,8 @@ on:
|
||||
push:
|
||||
branches: [main]
|
||||
tags-ignore: [dev]
|
||||
paths-ignore:
|
||||
- 'meetings/**'
|
||||
pull_request:
|
||||
branches: ['main', 'release-*']
|
||||
paths-ignore:
|
||||
- 'meetings/**'
|
||||
defaults:
|
||||
run:
|
||||
shell: bash
|
||||
|
||||
@@ -27,6 +27,11 @@ interested to hear about that!
|
||||
As always, you're more than welcome to [open an
|
||||
issue](https://github.com/bytecodealliance/wasmtime/issues/new) too!
|
||||
|
||||
Finally, we have biweekly project meetings, hosted on Zoom, for Wasmtime and
|
||||
Cranelift. For more information, see our [meetings agendas/minutes
|
||||
repository](https://github.com/bytecodealliance/meetings). Please feel free to
|
||||
contact us via Zulip if you're interested in joining!
|
||||
|
||||
## Finding Something to Hack On
|
||||
|
||||
If you're looking for something to do, these are great places to start:
|
||||
|
||||
@@ -1,3 +0,0 @@
|
||||
# Project meetings
|
||||
|
||||
Both Wasmtime and Cranelift have bi-weekly project meetings, open to all interested parties. See the [wasmtime](./wasmtime) and [cranelift](./cranelift) subdirectories for details on how to attend, agendas for upcoming meetings, and notes for past meetings.
|
||||
@@ -1,126 +0,0 @@
|
||||
# August 9 Cranelift project call
|
||||
|
||||
**See the [instructions](../README.md) 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
|
||||
@@ -1,145 +0,0 @@
|
||||
# August 23 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Sumbit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. cfallin: semantics of booleans (#3205)
|
||||
1. cfallin: instruction selection DSL (RFC 15)
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
in no particular order:
|
||||
|
||||
- CF: Chris Fallin
|
||||
- AB: Andrew Brown
|
||||
- B3: bjorn3
|
||||
- UW: Ulrich Weigand
|
||||
- SP: Sam Parker
|
||||
- AK: Anton Kirilov
|
||||
- Afonso Bordado
|
||||
- Johnnie Birch
|
||||
- BB: Benjamin Bouvier
|
||||
|
||||
### Notes
|
||||
|
||||
- Semantics of booleans: https://github.com/bytecodealliance/wasmtime/issues/3205
|
||||
- Inconsistencies between different backends
|
||||
- Tribal knowledge about this, mostly
|
||||
- New uses of boolean types, e.g. cg_clif
|
||||
- Q: should there be repr for a boolean type?
|
||||
- Q: what does it mean to have a bool that’s wider than 1 bit?
|
||||
- Historically, did have those wider-than-1 bit. Have to be all 0 or 1. Use
|
||||
case: bitcast from boolean to other types to get vector masks.
|
||||
- SIMD vector compare instructions are better handled for this use case
|
||||
- Q: what are the semantics of storing/loading bool from memory + casting to/from
|
||||
ints?
|
||||
- Historically, validator error to load/store bool from memory
|
||||
- Two main options:
|
||||
- A. false = 0, true = 1, wider-than-1-bit is 1 (zero-extended)
|
||||
- B. wider-than-1-bit is all ones
|
||||
- UW: b1’s documentation says it can’t be loaded/stored from/to memory
|
||||
- CF: not true as of last week (fuzz bug), need to update doc
|
||||
- AB: SIMD bool types must have a known bit repr
|
||||
- Q: do we want boolean types at the clif level to behave as the others (can be
|
||||
stored/loaded), or do we want to forbid memory accesses to those?
|
||||
- SP/UW: Do we know any arch that has sub-byte load/store? Sounds like
|
||||
no.
|
||||
- AB: fine to not mandate a repr on b1, but useful to have a repr for SIMD
|
||||
vectors, since bool vectors are likely to be stored
|
||||
- UW: doc is outdated for bool vectors (still mentions forbidden
|
||||
loads/stores)
|
||||
- Q: why do we want a bool type?
|
||||
- CF: we could just remove all the bool types overall
|
||||
- AB: what about return values of SIMD compare?
|
||||
- CF: only remove all the scalar bool types
|
||||
- UW: weird to have bool types only for vector
|
||||
- CF: could have b1 for scalar, and b128 for vectors, only
|
||||
- UW: what’s the benefit of e.g. b8 over i8 at the IR level?
|
||||
- CF: bitmasking stuff will depend on the actual IR type
|
||||
- AB: could remove a few `raw_bitcast` if we didn’t have so many bool
|
||||
types
|
||||
- CF: still want b1, do not allow load/store of bools, do not allow bitcast
|
||||
(they don’t have a repr)
|
||||
- B3: how would vselect work without bools?
|
||||
- AB: bool vectors give guarantees about the actual repr, so that’s nice
|
||||
- CF: can’t rely on lowering that the result of loading a b128 from memory is
|
||||
actually all ones or zeroes, so would have to canonicalize anyways
|
||||
- AK: could have shorter aarch64 sequences if we knew about the repr of
|
||||
bool vectors
|
||||
- AK: instead of canonicalization, could use pattern-matching up the
|
||||
operand tree that the value got produced by an inst that generated all0 or
|
||||
all1
|
||||
- CF: Proposal: we have wider bool types, and they are guaranteed to be
|
||||
canonicalized (insert checks for load/stores/bitcast). Impl could be
|
||||
compare-to-0?
|
||||
- UW: or shifts, depend on the situation. Would be a factor slower in any
|
||||
case.
|
||||
- AB: what about the use case where lowering wasm to clif, we load an
|
||||
v128 and use it as a mask in another wasm simd op?
|
||||
- CF: would need to cast to a bool type
|
||||
- Semantics of `raw_bitcast`?
|
||||
- Useful to convert from a CLIF type to another, without any change
|
||||
at the machine level
|
||||
- CF: think about it for some more time, and get back to it?
|
||||
- No one disagrees, so everyone agrees
|
||||
- Please make suggestions in the issue
|
||||
- ISLE: https://github.com/bytecodealliance/rfcs/pull/15
|
||||
- AK: want to be able to spend less/more time to do pattern-matching according to
|
||||
opt level. Would need runtime flags for this. Could this be implemented via the
|
||||
extractors?
|
||||
- CF: possible to have a switch at meta-compile time to exclude certain rules.
|
||||
Should it be a compile-time flag, or a runtime flag (more complicated)?
|
||||
- AK: really want a runtime flag to get really fast compile times
|
||||
- AK: also need a way to pattern match on CPU extensions
|
||||
- CF: would be a runtime flag as well
|
||||
- Afonso Bordado: commented about having this kind of predicates on instructions;
|
||||
proposal to use the `when` syntax
|
||||
- CF: implicit conditioning: no special marking, but if a rule uses an e.g.
|
||||
avx512-only inst, automatically detect it and add a predicate on the whole rule
|
||||
that it requires the CPU ext.
|
||||
- UW: how does it compare with LLVM?
|
||||
- CF: Studied related work in pre-RFC (#13). Pattern-matching DSL similar to what
|
||||
LLVM does. ISLE is less broad in scope than TableGen and would only be used
|
||||
for codegen. ISLE is simpler.
|
||||
- UW: in the LLVM community there’s been a push away from SelectionDag
|
||||
- CF: bigger compile times. It’s a tradeoff with dev productivity + we did have very
|
||||
subtle bugs in the past. LLVM moving to FastISel? because it’s faster. We’re
|
||||
building the foundational level of rules, “simple” pattern matching, nice to have a
|
||||
DSL at this point. How to make it fast in long run is an open research question.
|
||||
- UW: In LLVM, FastISel handles more common use cases and then redirects to
|
||||
SelectionDag if complicated cases show up. GlobalISel is supposed to be more
|
||||
global (can match across basic blocks).
|
||||
- CF: Could have a system with foundational rules + simple optimization rules that
|
||||
don’t try to match very deep.
|
||||
- AB: would like to try out some code when it’s ready so as to give more targeted
|
||||
feedback.
|
||||
- BB: risk of scattering code between Rust extern functions + high-level DSL.
|
||||
Some old problems are becoming new again. Reinventing many concepts
|
||||
present in legalization, concepts overload for newcomers. Risk of seeing bugs in
|
||||
the “system”, much harder to debug vs just looking at handwritten code. Tradeoff
|
||||
between developer experience and complexity, as said before.
|
||||
- CF: re: FFI, mostly isolated. re: complexity, “test and fuzz the crap out of it” :). Re:
|
||||
cognitive load, tribal knowledge is starting to appear in the current system (how
|
||||
to properly do pattern match without causing subtle errors?). Should be better in
|
||||
a lot of ways.
|
||||
- AK: emphasis on getting better documentation (blog posts / internal docs).
|
||||
- CF: if the system is complicated and requires lots of docs, it’s not ideal. Want to
|
||||
make the system easy to understand and have good docs.
|
||||
- AB: generated code should be in-tree, for better discoverability.
|
||||
- CF: agreed, would help compile times + we could maybe include comments in
|
||||
generated code.
|
||||
- Status updates:
|
||||
- UW: CI for s390, qemu patches now in main, some qemu version should work out of the
|
||||
box. Yet it (either qemu or wasmtime) doesn’t build anymore on s390. Looking into it
|
||||
before being able to run s390 in CI.
|
||||
- AK: more aarch64 tests run on qemu. Also have native runners.
|
||||
@@ -1,13 +0,0 @@
|
||||
# September 06 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
|
||||
*Canceled due to empty agenda and US holiday.*
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,204 +0,0 @@
|
||||
# September 20 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Sumbit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. Further discussion of ISLE, the proposed instruction selector DSL, as outlined in [RFC #15](https://github.com/bytecodealliance/rfcs/pull/15)
|
||||
|
||||
### Attendees
|
||||
|
||||
* cfallin
|
||||
* fitzgen
|
||||
* uweigand
|
||||
* alexcrichton
|
||||
* bjorn3
|
||||
* afonso360
|
||||
* akirilov
|
||||
* jlbirch
|
||||
|
||||
### Notes
|
||||
|
||||
#### ISLE
|
||||
|
||||
* cfallin - Hoping bbouvier could be here but conflict! Will catch up later. Anyone
|
||||
have any concerns to discuss?
|
||||
* jlbirch - what were concerns?
|
||||
* cfallin - not necessarily as "simple" as what we have right now. Currently
|
||||
everything is straightforward to jump in and "see" Rust code. Tracing things
|
||||
is easy and you can see what to modify. Also works with IDEs and rust-analyzer
|
||||
and other Rust tools. bbouvier wants to preserve this if possible since it's
|
||||
open and inviting, minimal knowledge required. Downside is that the benefits
|
||||
of the DSL aren't there, fitzgen and I mentioned on thread. There are
|
||||
some things we can only do with a DSL such as verification, optimizations,
|
||||
refactorings (new regalloc API), ... I think it's also more open and welcoming
|
||||
if you can understand the patterns and see them, that way you don't track
|
||||
subtle invariants from custom open-coding. More welcoming with custom language
|
||||
or to have Rust to read?
|
||||
* fitzgen - The goal of the DSL should be to thinking about the domain at hand
|
||||
rather than the low-level bits and I think it does a good job of that. If you
|
||||
see some lowering is missing adding the new operation should be writing a
|
||||
pattern and just focusing on the pattern, not also how it fits into the
|
||||
hand-written matcher-trees. With the DSL compiler handling all that it's nice
|
||||
that it handles performance (optimized lowering) but you're also just talking
|
||||
about the pattern you want to match instead of manually doing the lowering.
|
||||
* cfallin - aspect oriented programming anyone? The DSL brings all the little
|
||||
things spread throughout the code into one place in the compiler -- raising
|
||||
the level of abstraction and not having to worry about doing unsafe or illegal
|
||||
things. Understand Ben's concerns though. Anyone else have similar concerns?
|
||||
* akirilov - I'm in the middle, leaning towards what you're describing with
|
||||
ISLE.
|
||||
* jlbirch - Worked on compilers awhile ago! No DSL involved. Mostly with
|
||||
bytecodealliance I've seen DSLs. Would ISLE looks similar to the wasm backend
|
||||
for v8?
|
||||
* cfallin - not familiar with v8, but you/Andrew have described open-coding, is
|
||||
that right?
|
||||
* jlbirch - looking at a lowering language of some sorts
|
||||
* cfallin - link?
|
||||
* jlbirch - should be able to compare what we have to v8 and how it's easy to
|
||||
look at and dive in. Haven't had experience debugging v8 though and that's
|
||||
presumably where the issues come in.
|
||||
* cfallin - speaks to a tooling concern and trace what some code becomes and
|
||||
why. The output of the DSL should be human readable and should ideally have
|
||||
comments for where things came from. Does this in the prototype, not beautiful
|
||||
code but still readable. Has comments though and says "this came from ISLE
|
||||
line 123". Should be able to step through and see various cases. Maybe higher
|
||||
level thing like log/trace to show what was applied? I understand the
|
||||
debugging point though, very important.
|
||||
* fitzgen - regarding what other compilers do, gcc has its own DSL, LLVM has
|
||||
tablegen, Go has a DSL for this sort of thing. ISLE does have unique things
|
||||
but this shouldn't be too too foreign.
|
||||
* cfallin - "term rewriting system" - studied for awhile -- not to say it's
|
||||
automatically easier. Is understood though.
|
||||
* jlbirch - Yeah understand it's not too too crazy. Trying to imagine someone
|
||||
with no experience in compilers jumping in.
|
||||
* cfallin - Trying to prevent bugs that have come in with ISLE preventing things
|
||||
from being incorrect. Lots of stuff to worry about today with
|
||||
regalloc/metadata/sinking loads/etc. Extra mental state we don't want authors
|
||||
to have to carry with ISLE.
|
||||
* jlbirch - generally agree
|
||||
* cfallin - should catch up with Ben later. Sounds like others agree?
|
||||
* akirilov - haven't touched the old backend which seems like it has a somewhat
|
||||
similar DSL. Would be good to have a guide for how to add a new instruction.
|
||||
Main challenge is that there's no guide right now and would be helpful to
|
||||
have. Good to know how to add one instruction and to debug.
|
||||
* cfallin - good idea!
|
||||
* akirilov - ideally information is close to the project (as opposed to blog
|
||||
posts, which are great!) since contributors may not always be aware of
|
||||
articles. We have Wasmtime guide with section for contributing? Doesn't cover
|
||||
Cranelift though.
|
||||
* cfallin - Whole `docs` repo to write stuff into, would be great to do.
|
||||
* fitzgen - would be good to have Cranelift-specific book.
|
||||
* cfallin - yes!
|
||||
* akirilov - should link from the Wasmtime book since it appears at the top of
|
||||
the repository. Cranelift should be visible too.
|
||||
* cfallin - agreed! Should document new instructions, new lowerings. Could
|
||||
probably source from RFCs and such.
|
||||
* cfallin - brief mention of progress. The prototype of ISLE exists and they can
|
||||
dig into it. Happy to explain more in a call. Nick is going to try to carry
|
||||
forward and implement more things end-to-end with polish. Nick?
|
||||
* fitzgen - Plan is to get one lowering implemented all the way through with
|
||||
ISLE and then try ISLE first in existing lowering, falling back to handwritten
|
||||
thing. Afterwards knocking out all the patterns. Probably still a week or so.
|
||||
This'll quickly be parallelizable where it's mostly just porting patterns,
|
||||
talk to me!
|
||||
* jlbirch - will do my homework and reread these issues and will take you both
|
||||
up on the offer and plan to help out
|
||||
* fitzgen - Looking at pattern -> Rust code translation was very helpful and
|
||||
gave me confidence that it's doing what it should do. Confident approach is
|
||||
nice and could understand well that what I'm doing maps well.
|
||||
* cfallin - any other thoughts on ISLE?
|
||||
|
||||
|
||||
#### Endianness
|
||||
|
||||
* cfallin - Thank you s390x for making sure we're correct here! Consensus last
|
||||
year we have tri-state approach, we have a little/big/native flag on all
|
||||
loads/stores. Native important for interacting with the rest of the system.
|
||||
Concern that with the interpreter that this makes clif behavior
|
||||
platform-dependent. Should have a single defined semantics for clif to prevent
|
||||
breaking things up the stack. The suggestion in the issue is that we
|
||||
reconsider this and go back to a world where have explicit endian on
|
||||
everything, and for native things we bake it in based on the knowledge when we
|
||||
generate the clif. Basic approach is to do what other compilers do like LLVM
|
||||
with early-bind rather than late-bind. Any objections?
|
||||
* akirilov - agree! Especially about clif semantics I agree we don't want them
|
||||
dependent on the interpreter's host platform.
|
||||
* cfallin - ok sounds like not much controversy. Sticky point is the API change.
|
||||
When you create a clif function or you get a builder you need to give a notion
|
||||
of endianness if not more platform information. Corresponds to LLVM which has
|
||||
datalayout at the top of every file. Don't think that this will break things
|
||||
other than that it's an API change which you should already know.
|
||||
* uweigand - Confused about how other IRs have been created from the start for a
|
||||
particular target and will build different IR for different targets. Have to
|
||||
know the target for the IR to do anything with it anyway. Need to keep
|
||||
specifying the same target when working with the same file. Or LLVM annotates
|
||||
at the top. Sometimes datalayout also has target too. Having an interpreter
|
||||
which doesn't know the intended target will really fully work even if
|
||||
endianness is fixed. Won't there be other reasons?
|
||||
* cfallin - one distinction is that the specific target is less important and
|
||||
more important about details like endianness. Native loads/stores defined by
|
||||
this. Pointer width can also be important. If you give me x86 IR it should be
|
||||
possible to in theory compile on a 64-bit big-endian system with byteswaps?
|
||||
* uweigand - don't have a full overview of the IR, but wondering if we have
|
||||
things like pointer offsets which changes offsets and such?
|
||||
* cfallin - not in the same way of LLVM, the code producer might assume this and
|
||||
we may want to check. How would this work. If we're lowering heap_addr on
|
||||
64-bit system from IR targeted from 32-bit system maybe...
|
||||
* uweigand - the specific question seems fine here, tried last year and it
|
||||
seemed possible. Lots of code to change though, including code outside of the
|
||||
Cranelift repository.
|
||||
* cfallin - no API stability right now though. Folks here produce clif IR so
|
||||
this would impact you. Providing endianness to a builder isn't the biggest
|
||||
dealbreaker though since it's often ...
|
||||
* fitzgen - to what uweigand said, the front/middle generate different IR
|
||||
depending on the backend. Are we doing this today in Cranelift? All else being
|
||||
equal it would be nice if we always generated the same IR. Some issues with
|
||||
endianness though. I liked you recent comment of setting the endianness once
|
||||
and still a tri-state native option, but native is explicitly defined. If the
|
||||
declaration of what native is the only thing that's different that seems like
|
||||
a nice property.
|
||||
* uweigand - to clarify I wasn't referring to Cranelift, referring to compilers
|
||||
like gcc/LLVM where it generates different IR since IR already encodes
|
||||
features like the calling convention, struct sizes, etc.
|
||||
* cfallin - we don't have calling convention details but we do have struct
|
||||
layout depending on what the producer is doing. No concept of struct in
|
||||
cranelift, but we do have producers that compile structs. Pointer-width fields
|
||||
have different sizes.
|
||||
- acrichto - wasmtime has platform dependent things for VMContext yeah
|
||||
- afonso - control type for stack\_addr and such is pointer type
|
||||
- cfallin - if you use 32-bit on 64-bit should be compiled correctly? Would be
|
||||
nice to be independent but there's lots of details
|
||||
- fitzgen - imagining on the cranelift-wasm frontend it's the same
|
||||
- cfallin - I think it's already true except argument loads/stores?
|
||||
- uweigand - other way around. All loads/store have explicit endianness. More
|
||||
places "leave native" than use little. Most probably use little-endian though
|
||||
since it's wasm.
|
||||
- cfallin - almost have this property nick? maybe don't enforce?
|
||||
- fitzgen - we have environment traits which customize things we want different.
|
||||
Not mad about hook points for those using the frontend. If cranelift-wasm
|
||||
decides to ask about the current platform and change the lowering that feels
|
||||
bad.
|
||||
- cfallin - agreed that's bad. This should be used to make behavior
|
||||
deterministic. Don't have other platform-specific properties.
|
||||
- bjorn3 - how test native loads/stores?
|
||||
- cfallin - different tests? No duplication? Not sure I understand.
|
||||
- cfallin - other points? Ok sounds like a reasonable approach, Afonso would you
|
||||
like to try this?
|
||||
- afonso - Will probably need guidance but happy to try.
|
||||
|
||||
#### Status
|
||||
|
||||
- cfallin: ISLE!
|
||||
- uweigand: s390x - final patches merged and testsuite passes out-of-the-box. PR
|
||||
to add s390x to CI. As we were speaking the run finished!
|
||||
- akirilov: looking into pointer authentication support and code branch target
|
||||
indication. These two are related. Just starting to working on an RFC since
|
||||
this will probably merit discussions.
|
||||
@@ -1,168 +0,0 @@
|
||||
# October 4 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Sumbit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. Further discussion of [ISLE DSL](https://github.com/bytecodealliance/rfcs/pull/15)
|
||||
- Quick ISLE tutorial ([slides](https://docs.google.com/presentation/d/e/2PACX-1vTL4YHdikG70GZuWvnUOqWdE31egZDBj-2-ajsNfoLkeUn8Bpvk_a5vEFOQqsolcUuR9pmYj2qPF-_J/pub))
|
||||
|
||||
### Attendees
|
||||
|
||||
- cfallin
|
||||
- fitzgen
|
||||
- bbouvier
|
||||
- akirilov
|
||||
- uweigand
|
||||
- bjorn3
|
||||
- alexcrichton
|
||||
- afonso
|
||||
|
||||
### Notes
|
||||
|
||||
* cfallin - one thing on agenda! -- ISLE
|
||||
* cfallin - made more progress, Nick has been improving the prototype posted
|
||||
awhile back. It's generating Rust code for the basic concepts and Nick's been
|
||||
improving and adding error reporting. Driving Cranelift integration, assuming
|
||||
we do this, as well
|
||||
* cfallin - continued discussion today to make sure that this is what we want to
|
||||
do. Lots of good discussion points raised in the RFC. Nick has some slides if
|
||||
folks would find that useful. Shows some code generated. After that some open
|
||||
discussion?
|
||||
|
||||
... slides! ...
|
||||
|
||||
* cfallin - concerns after presentation?
|
||||
* uweigand - not really a concern but need details like special cases and
|
||||
particular constants in particular ranges. Can always do whatever since it's
|
||||
custom Rust. Always cases to do something special.
|
||||
* cfallin - special cases are extractors and constructors -- becomes a trait
|
||||
method and you can write whatever you want. In the extreme can do it all in
|
||||
Rust with one method, but everything beyond that is making use of
|
||||
functionality for pattern matching.
|
||||
* uweigand - another question - is this going to be another big bang from the
|
||||
old way to the new way?
|
||||
* cfallin - no first goal was a migration story, the idea being that this will
|
||||
be driven by doing the "new thing" first and falling back to the "old thing"
|
||||
if `None` is returned. Will put ISLE in place, start with "add" or something,
|
||||
ask for help with PRs. Individual instructions should be simple and when it's
|
||||
all done we can remove the old way.
|
||||
* akirilov - second escape hatch!
|
||||
* cfallin - yes still have old way where we can use if ISLE can't handle
|
||||
something and we can figure out later if we need to add something to ISLE
|
||||
* bbouvier - what if ISLE generates slower Rust than what we do today, we won't
|
||||
figure this out with incremental rewrite and would need to compare two points
|
||||
in time which could have other changes in the middle. Hard to measure?
|
||||
* cfallin - should have no performance regressions by construction. Should
|
||||
generate the same code that we're writing by hand. Shouldn't have regressions
|
||||
at this time. If many more complicated patterns arise then we should be in
|
||||
theory generating better code. In the future we write more complicated code
|
||||
with more complicated patterns that's a new state. Today though we should
|
||||
strive to make sure the generated code matches what we do today.
|
||||
* akirilov - can check for regressions with current backends by not deleting
|
||||
code in current backends and skipping ISLE to do comparison.
|
||||
* cfallin - true, can add all the things and delete separately, but the downside
|
||||
is that we have two sources of truth with possible divergences. Have the
|
||||
flexibility of doing that though.
|
||||
* bbouvier - risk that there is an exponential growth of pattern matching trees.
|
||||
Could two rules interact in a way that they do deeper matching? Hard to test
|
||||
we didn't do that in particular with incremental rewrite.
|
||||
* cfallin - could be interesting interactions, yeah, currently a property is
|
||||
that the output of ISLE is linear in the input size. No iteration to a fixed
|
||||
point in combining rules, it instead does only a single layer. Shouldn't get
|
||||
exponential blowup in that regard but could be interesting interactions
|
||||
perhaps though, but none over what we already do.
|
||||
* bbouvier - concern about verbosity - if a specific rule is commutative do you
|
||||
need to write a rule twice? Or systemic checks about commutativity?
|
||||
* cfallin - nothing like that right now, would write it twice. Idea is to have
|
||||
it be simple first. If we express and can lower it simply then we can do that
|
||||
as well yeah.
|
||||
* fitzgen - I think this is a non-issue since we already have `iadd_imm`
|
||||
canonicalized by the preopt pass, no need to re-canonicalize in lowerings.
|
||||
* cfallin - still good question if we can express a family of patterns. We could
|
||||
have a macro system perhaps in the futures where one rule goes to N rules, but
|
||||
maybe too much complexity too. For now cases should be simple enough.
|
||||
* fitzgen - gcc/go have macro in their DSL to be polymorphic over bit-width.
|
||||
* cfallin - for that specific case we could perhaps be polymorphic on types by binding the type with a pattern variable
|
||||
|
||||
... more may be lost as alexcrichton had video issues and dropped ...
|
||||
|
||||
* cfallin - if we have few weird special cases easier to consume than a more
|
||||
general form.
|
||||
* bbouvier - main concern is about the developer experience. The systems seem
|
||||
reasonable. Having a very simple tutorial is a great thing though. Seems great
|
||||
at solving 95% of the problems and for the remaining 5% you need to be an
|
||||
expert (meaning writing your own extractor), but maybe this is the right
|
||||
tradeoff? It's a regression to deal with two kinds and not see how they
|
||||
interact. Embedding concepts from one language in another can be tricky.
|
||||
* cfallin - type definitions? Probably need a better story such as generating
|
||||
that automatically. Could parse Rust definitions in the future? Makes sense
|
||||
about two different languages though. I think this is a fundamental thing that
|
||||
we would buy into. ISLE has s-expressions that aren't Rust, but in exchange
|
||||
we're buying a lot of power. Once everything in ISLE we can change the
|
||||
compiler or change the trait methods and it's much easier to make more
|
||||
widespread changes. One concrete example is a migration to regalloc2. Started
|
||||
down path with handwritten code and stopped at a 4k line diff since everything
|
||||
needed to change. If we generate the code we change things once and everything
|
||||
"just works". Additionally big thing is consuming the pattern for purposes
|
||||
other than the backend such as verification or analysis. Tooling to understand
|
||||
the list of rules as data benefits from ISLE. Can theoretically do things like
|
||||
this today but can be difficult. May as well extract core rules as explicit
|
||||
list.
|
||||
* bbouvier - makes sense but you can imagine that there could be some issues
|
||||
with a source-to-source compiler since you debug Rust code instead of ISLE.
|
||||
Have to understand what to do in one source to induce changes in the other.
|
||||
Lose tools like rust-analyzer with a custom language. Understand a new
|
||||
framework can enable new things but as an end-user I would lose quality of
|
||||
life a lot.
|
||||
* cfallin - unsure, I hear where you're coming from in that it's a new thing
|
||||
with no tooling that Rust has for example. As debugging the best you'd get is
|
||||
what you see where rules came from. This is a fundamental tradeoff though in
|
||||
that we're paying complexity for power, but I think the power comes for the
|
||||
backend developer too. A simpler DSL than handwritten-today enables a better
|
||||
backend. SIMD in particular is very deeply nested and tangled. A series of
|
||||
patterns makes life easier as an instruction lowering engineer.
|
||||
* fitzgen - you said early 95% easy and 5% expertise, I think this is a much
|
||||
better ratio than where we're currently at. I think the level of indirection
|
||||
is a hit we'll take since we aren't going to build an LSP. All the other stuff
|
||||
seems worth it to me though.
|
||||
* cfallin - as a former hand-developer this is something I want, but bbouvier
|
||||
you write much code to so if you don't want this then that's just two
|
||||
anecdotal data points. Concern is can we live with it and if it's necessary
|
||||
for other things, without hindering other goals, then is it worth it?
|
||||
Subjective call.
|
||||
* bbouvier - understand you want verification and such. You who are active
|
||||
maintainers makes sense you do what feels best. I'm not against this just a
|
||||
bit skeptical.
|
||||
* cfallin - no asking questions is very valuable. If this isn't the right thing
|
||||
we shouldn't do this, it's an open question. I think that this is valuable
|
||||
even if we don't do things like verification, for the common case of writing
|
||||
the backend in hindsight this is what I would have wanted. I would give myself
|
||||
the ISLE compiler in 2020 if I could. May be biased now though. Can be scary
|
||||
s-expressions for newcomers, but may be able to be simpler to define new
|
||||
instructions.
|
||||
* fitzgen - thanks again for asking questions and pushing, know that it's hard
|
||||
when others aren't speaking up. One thing I think may be useful would be
|
||||
thinking about if we do do ISLE what can we do to mitigate the loss in
|
||||
developer experience around these boundaries? Comments in generated source
|
||||
today but what else can we do?
|
||||
* cfallin - Would second that question, open to input for ideas. Not asking for
|
||||
a vote on the RFC, we'll continue to work on the prototype and at a point not
|
||||
too far distant we'll be able to see integration with Cranelift. Hopefully
|
||||
will see a simplification and benefits can be more clear.
|
||||
* akirilov - I'd like to try to implement one of the hairiest things to see how
|
||||
it goes in addition to seeing simple examples.
|
||||
* fitzgen - would be good for having a deadline of deciding to do this. My plan
|
||||
is to integrate with cranelift soon, simple and hard ones. Could we come back
|
||||
and take a look and not be stuck in limbo?
|
||||
* akirilov - sounds reasonable yeah. Good to have simple examples to see how
|
||||
things work and complicated ones as well to see how far we can push ISLE.
|
||||
* bbouvier - yeah sounds good.
|
||||
* cfallin - over time! Thanks all!
|
||||
@@ -1,107 +0,0 @@
|
||||
# October 18 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Sumbit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. (fitzgen) update on ISLE integration
|
||||
1. _Sumbit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
- cfallin
|
||||
- fitzgen
|
||||
- acrichto
|
||||
- uweigand
|
||||
- bjorn3
|
||||
- sparker
|
||||
- jlbirch
|
||||
- bbouvier
|
||||
|
||||
### Notes
|
||||
|
||||
#### ISLE
|
||||
|
||||
- fitzgen: first few rules working and integrated into Cranelift with tests
|
||||
passing, (few == 3, iconst, bconst, and catch-all for add). Glue isn't too bad
|
||||
and now plan to work on complicated lowerings next. If there are ideas of
|
||||
things to prove out the DSL let me know. Next is add with sinking loads, add
|
||||
with an immediate, popcnt lowering, compare-and-branch, etc. Hope to have
|
||||
final yay/nay in 2 weeks. Personally have enjoyed ISLE so far and it was
|
||||
super-easy to add case to 0-immediates are xor reg/reg. Didn't involve fitting
|
||||
into match tree and was nice to write as a standalone rule.
|
||||
- cfallin: gist?
|
||||
- fitzgen: not PR ready but sure!
|
||||
- cfallin: this is definitely something I would have wanted last year, but take
|
||||
that with a grain of salt. Need to evaluate whether it's worth the complexity.
|
||||
Any questions/comments?
|
||||
- cfallin: no vote today at all, just a progress update, but after two weeks
|
||||
hopefully will find consensus one way or another to move forward. Hope to make
|
||||
a decision soon though so this doesn't continue indefinitely.
|
||||
- fitzgen: plan to have enough by next mtg for sure, yeah.
|
||||
- jlbirch: which aspect is this supplementing or replacing? [the files posted]
|
||||
- fitzgen: the handwritten match statements in lowering code going from clif to
|
||||
machinst.
|
||||
- jlbirch: these looks like comments for types and not instructions?
|
||||
- cfallin: oh there's inst.isle and lower.isle
|
||||
|
||||
...
|
||||
discussion of
|
||||
https://github.com/fitzgen/wasmtime/blob/isle/cranelift/codegen/src/isa/x64/lower.isle
|
||||
...
|
||||
|
||||
...
|
||||
discussion of
|
||||
https://github.com/fitzgen/wasmtime/blob/isle/cranelift/codegen/src/isa/x64/inst.isle
|
||||
...
|
||||
|
||||
- sparker: looks quite good for addressing modes on memory operations
|
||||
- fitzgen: next goal for me!
|
||||
- bjorn3: looks like a lot of new dependencies?
|
||||
- fitzgen: uses miette - current branch unconditionally rebuilds isle crate,
|
||||
but shouldn't have to rebuild any of this unless you're changing various data
|
||||
types. Most don't touch this, so dependencies should only matter if you're
|
||||
actively hacking on these areas.
|
||||
- cfallin: eventually we may not have the meta step or might check in more of
|
||||
the code. Would improve build times by a lot, but this is a separate
|
||||
discussion with different pros/cons. If build time is a concern there are
|
||||
avenues to take.
|
||||
|
||||
#### Status
|
||||
|
||||
- cfallin: not much, working on non-cranelift things. RA2 progressing a bit,
|
||||
jseward planning on finishing review for regalloc.rs adapter. Should be able
|
||||
to release to crates.io after that and license bits sorted.
|
||||
- fitzgen: no other updates than from above.
|
||||
- bbouvier: no update
|
||||
- acrichto: no update
|
||||
- jlbirch: starting to look at some fuzz bugs
|
||||
- uweigand: working on atomics, everything is cas loops, tedious. Seems like
|
||||
clif supports a lot of atomic ops which are easy on x86 as a single
|
||||
instruction but not as easy on other platforms. Should we remove bits from
|
||||
clif ir?
|
||||
- cfallin: github issues to remove things and can discuss there?
|
||||
- uweigand: building wasi binaries from Rust needs a linker which isn't
|
||||
available on s390x.
|
||||
- sparker: looking at flexible vectors, gonna try to put into cranelift somehow.
|
||||
Hoping to use ISLE to convert between flexible vectors and neon.
|
||||
- cfallin: new clif instructions?
|
||||
- sparker: using existing instructions but getting size of vector into system
|
||||
and have backends never see it later ideally.
|
||||
- cfallin: feel free to post an issue and we can discuss there too
|
||||
- jlbirch: based on flexible vector proposal?
|
||||
- sparker: yes
|
||||
- jlbirch: I would be interested! Would be great to have shared infrastructure.
|
||||
- sparker: hoping to separate into 3 tiers, first being current simd. Want to
|
||||
have shared infrastructure to map to existing targets first.
|
||||
- bjorn3: cleaning up after old x86 backend removal
|
||||
- cfallin: great to see so much deleted!
|
||||
@@ -1,83 +0,0 @@
|
||||
# November 1 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Sumbit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. (fitzgen) ISLE presentation; discussion; decision.
|
||||
* [slides](https://docs.google.com/presentation/d/1b6psjaIKkVTZGaGzMcw9h_Ahgih-ctUcnz0Dbjn11GI/edit)
|
||||
3. _Sumbit a PR to add your item here_
|
||||
|
||||
### Attendees
|
||||
|
||||
* cfallin
|
||||
* fitzgen
|
||||
* sparker
|
||||
* akirilov
|
||||
* acrichto
|
||||
* jlbirch
|
||||
* bjorn3
|
||||
|
||||
### Notes
|
||||
|
||||
#### ISLE
|
||||
|
||||
* cfallin: one item for today, Nick's presentation on ISLE!
|
||||
* fitzgen: ... makes presentation ...
|
||||
* cfallin: main result now is whether or not we start the FCP process, any
|
||||
showstopper concerns at this point?
|
||||
* jlbirch: what happens next if we move forward?
|
||||
* cfallin: there's a section in the RFC, but the idea is that at the top level
|
||||
ISLE is used and if it returns `None` use what's there today, a top-level
|
||||
switch. We'll merge the framework and write more lowering in the DSL over
|
||||
time, but the old backend is there the whole time. Everything can still be
|
||||
handled because it's the fallback case. When the last logic is added to ISLE
|
||||
we can delete the old backend as it's not used.
|
||||
* jlbirch: would be great to compare and have baseline yeah
|
||||
* bjorn3: no new build deps?
|
||||
* cfallin: yes will check in build code. I will make a motion to finalize and
|
||||
will need another group to +1. Once RFC has merged we can merge the prototype
|
||||
and go from there. Any objections?
|
||||
|
||||
#### Status
|
||||
|
||||
* cfallin: no updates
|
||||
* fitzgen: my presentation!
|
||||
* jlbirch: no updates
|
||||
* akirilov: working on prototype for CFI. Function prologues now need to be
|
||||
ISA-specific and requires changes. Working on getting all tests passing with
|
||||
prototype.
|
||||
* acrichto: ... questions about CFI and Rust implications ...
|
||||
* sparker: working on flexible vectors, got an example working with splat + add.
|
||||
Some questions! Hard limit of 256 lanes?
|
||||
* cfallin: probably an efficient representation? Likely predates much of us. Is
|
||||
there a statically defined but arbitrary vector size? or dynamic?
|
||||
* sparker: proposal should be dynamic as a value in SSA form. Implemeneted for
|
||||
AArch64 so just return 128 sizes. Wondering if I can take a bit to represent a
|
||||
dynamic vector.
|
||||
* cfallin: seems unlikely to have more than 256 lanes so seems fine.
|
||||
* sparker: looks like an opaque vector and the return value is that it's a
|
||||
size-less vector.
|
||||
* cfallin: seems safe because lots of code may cast. Arbitrary size so is it in
|
||||
a register?
|
||||
* sparker: it's in a register and gets weird if you do lane operations. Special
|
||||
immediate type there. Can't do some things you can do in fixed-width nicely.
|
||||
* cfallin: feels like an arbitrarily sized types. Seems more like a struct than
|
||||
a fixed-width vector. Feels right to make it a new kind of thing though.
|
||||
* akirilov: this sounds like a similar situation in LLVM
|
||||
* sparker: represented as a vector in LLVM so IR shows vector code and the width
|
||||
is the minimum width. Flexible vectors aren't well-defined really.
|
||||
* cfallin: advantage of using existing infrastructure would be for future use
|
||||
with tiling/blocking but unsure if it's useful enough for now.
|
||||
* sparker: looking to not have to update all the "is this a vector" blocks
|
||||
* cfallin: seems like the right thing to do for prototyping and can figure out
|
||||
more details later.
|
||||
* bjorn3: no updates
|
||||
* cfallin: I will motion to finalize the ISLE RFC. That should be it!
|
||||
@@ -1,79 +0,0 @@
|
||||
# November 15 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Sumbit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Sumbit a PR to add your item here_
|
||||
|
||||
### Attendees
|
||||
|
||||
* Alexa VanHattum
|
||||
* abrown
|
||||
* akirilov
|
||||
* alexcrichton
|
||||
* bbouvier
|
||||
* bjorn3
|
||||
* cfallin
|
||||
* fitzgen
|
||||
* jlbirch
|
||||
* uweigand
|
||||
|
||||
### Notes
|
||||
|
||||
* cfallin: merged ISLE RFC, ended FCP this morning. Need to review compiler &
|
||||
integration, shouldn't take too long hopefully. How to prioritize moving over
|
||||
afterwards? I think we should enable moving everything over reasonably
|
||||
quickly. Will unlock improvements to backend design such as RA2. How do others
|
||||
feel about helping migration?
|
||||
* uweigand: Agreed ASAP. Busy working on .NET recently, but release is over!
|
||||
Look to do more Wasmtime work soon.
|
||||
* jlbirch: Also agreed ASAP, and should have time to help.
|
||||
* cfallin: I'll spend time writing docs for the DSL itself.
|
||||
* fitzgen: Wrote an overview awhile back and need to write more, yes.
|
||||
* akirilov: should have more time next quarter
|
||||
* uweigand: can migrate one-by-one, right?
|
||||
* cfallin: indeed!
|
||||
* abrown: how much of x64 is left to do?
|
||||
* fitzgen: unsure on lines of code, but integer arithmetic is all ported. Alex
|
||||
has more SSE stuff as well. Maybe halfway?
|
||||
* cfallin: ballpark estimate nick?
|
||||
* fitzgen: few weeks?
|
||||
* uweigand: only simple things?
|
||||
* fitzgen: complicated things too like i128 and SSE things. For example `shl`
|
||||
for i128 is quite large. Currently porting on-by-one as I go through the big
|
||||
`match`.
|
||||
|
||||
#### Status
|
||||
|
||||
* cfallin: internal project mostly, got info from Mozilla it's ok to relicense
|
||||
regalloc2 and then "all" we need to do is to review the compatibility shim to
|
||||
regalloc.rs API. Alternatively if timing goes the other way if we transition
|
||||
to ISLE happens we can port directly to the pure SSA API, but ISLE does
|
||||
everything that would otherwise be done by hand. Still some benefits with a
|
||||
compat shim to compile time but more benefits with SSA API. Will write docs on
|
||||
ISLE soon.
|
||||
* fitzgen: Lots of ISLE. Also work on `wasm-mutate` is progressing. Also ran
|
||||
benchmarks for ISLE and good results.
|
||||
|
||||
... discussion of `wasm-mutate`, wasmtime fuzzing, veriwasm, ...
|
||||
|
||||
* acrichto: random ISLE x64 lowerings
|
||||
* bbouvier: no updates
|
||||
* akirilov: mostly internal thing. Things about CFI as well. Will need to change
|
||||
proposal a bit for a rustc backend.
|
||||
|
||||
... discussion about CFI ...
|
||||
|
||||
* uweigand: no updates, next step is to implement atomics. Will wait for ISLE
|
||||
before adding SIMD.
|
||||
* abrown: no updates
|
||||
* bjorn3: no updates
|
||||
* jlbirch: simd fuzz bug fix
|
||||
@@ -1,79 +0,0 @@
|
||||
# November 29 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Sumbit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. Bug scrub - Maybe this belongs as a Wasmtime open but there are 369 Wasmtime issues dating back to 2016. Surely many are cranelift specific where many are bugs likely in code that no longer exists. What's the best way to scrub these?
|
||||
|
||||
### Attendees
|
||||
|
||||
* Alexa VanHattum
|
||||
* abrown
|
||||
* akirilov
|
||||
* alexcrichton
|
||||
* bjorn3
|
||||
* cfallin
|
||||
* fitzgen
|
||||
* jlbirch
|
||||
|
||||
### Status
|
||||
|
||||
* cfallin: two PRs with documentation! Nick has documented language bindings for
|
||||
Cranelift and how to get started with new lowerings. I also posted docs for
|
||||
ISLE language semantics itself. Should ideally be clear how language works and
|
||||
how to add lowerings. Plan on working on a roadmap for 2022, similar to
|
||||
pseudo-rfc document of last year. Let me know if you have ideas! RFC coming
|
||||
soon.
|
||||
* fitzgen: worked on documentation and ISLE.
|
||||
* alexcrichton: Worked on AArch64 ISLE tidbits. Initial lowering and some sample
|
||||
instructions.
|
||||
* alexcrichton: along the lines of toml-defined `MInst` I thought porting to
|
||||
ISLE worked quite well.
|
||||
* fitzgen: eventually want more information for things like register allocation
|
||||
too.
|
||||
* alexcrichton: perhaps an ISLE "annotation" syntax?
|
||||
* ... more discussion of how best to represent this ...
|
||||
* akirilov: sam has a prototype for flexible vectors. Working on understanding
|
||||
ISLE and trying to use it. For me there's a PAC prototype and fixing some
|
||||
tests.
|
||||
* abrown: Fixed a too-tight assertion. Wanted to switch `select` to ISLE but
|
||||
seemed significant. Fuzzing for simd was also turned on this past week?
|
||||
* alexcrichton: ah yes! Fuzzing enabled over Thanksgiving and no new fuzz bugs
|
||||
have appeared.
|
||||
* alexa: is it known simd is being fuzzed?
|
||||
* ... discussion of wasm-smith and csmith heritage ...
|
||||
* jlbirch: work on wasm64, more coming soon...
|
||||
* bjorn3: work on getting the blog os compiling with cg_clif
|
||||
* alexa: working on starting to verify the correctness of individual instruction
|
||||
lowerings in ISLE.
|
||||
|
||||
### Bug Scrubbing
|
||||
|
||||
* jlbirch: lots of really old bugs and wondering if we should scrub some old
|
||||
bugs and close out?
|
||||
* cfallin: one roadmap item is stability and push for quality. Tech debt that
|
||||
needs to be finished and things like that. If anyone wants to go through issue
|
||||
in free time that's always appreciated. Perhaps can organize something early
|
||||
next year.
|
||||
* akirilov: are wasmtime issues still applicable?
|
||||
* cfallin: part of task is probably labeling anything with a codegen component
|
||||
as cranelift.
|
||||
* akirilov: are there guidelines for labeling issues?
|
||||
* fitzgen: labels good for discovery so I don't think there's any need to be
|
||||
stingy.
|
||||
* abrown: some old issues probably need some more labels, e.g. some x64 labels.
|
||||
Triage sounds like a good idea.
|
||||
* akirilov: is there duplication in the labels?
|
||||
* cfallin: haven't removed any labels ever! Can certainly triage labels
|
||||
themselves too.
|
||||
* fitzgen: if interested in specific areas we do have the tagging bot to get
|
||||
tagged for certain labels. Another bot to automatically label PRs with changes
|
||||
in certain subdirectories.
|
||||
@@ -1,60 +0,0 @@
|
||||
# December 13 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Sumbit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Sumbit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
* Chris Fallin
|
||||
* Nick Fitzgerald
|
||||
* Alexa VanHattum
|
||||
* Ulrich Weigand
|
||||
* Anton Kirilov
|
||||
* Johnnie Birch
|
||||
* Benjamin Bouvier
|
||||
|
||||
### Notes
|
||||
|
||||
* Chris Fallin:
|
||||
* project update blog post is out
|
||||
* 2022 roadmap is out, please leave comments / suggestions / feedback on the
|
||||
RFC
|
||||
* Nick Fitzgerald:
|
||||
* ISLE porting
|
||||
* wasm-mutate stuff, lots of "good first issue" type stuff if people want to
|
||||
contribute!
|
||||
* Alexa VanHattum:
|
||||
* Been looking into verifying ISLE
|
||||
* `iadd`s that compile down into `sub`s
|
||||
* SAIL(sp?) seems easier to work with in aarch64 than x86-64, probably
|
||||
starting there
|
||||
* Ulrich Weigand
|
||||
* Looking into ISLE
|
||||
* Anton Kirilov
|
||||
* Finished an initial pointer auth impl in aarch64 backend
|
||||
* Going to start working on BTI support
|
||||
* Issues with A vs B keys and unwinder
|
||||
* Current pauth prototype doesn't use nop-space instructions
|
||||
* Need to figure out how this integrates with Wasmtime's fibers
|
||||
* Apple ABI docs suggest that you can just find the return pointer and frame
|
||||
pointer as long as you don't keep arbitrary code pointers in registers
|
||||
* Johnnie Birch
|
||||
* Doing a little benchmarking work
|
||||
* Triaging and cleaning up old issues, could use some help from anyone who has
|
||||
time
|
||||
* Benjamin Bouvier
|
||||
* No updates
|
||||
* Andrew Brown (via Johnnie/Chris)
|
||||
* Working on the ISLE lowering for `select` on x64
|
||||
@@ -1,93 +0,0 @@
|
||||
# January 10 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. Testing strategy; golden tests and auto-updating (PR #3612)
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
- abrown
|
||||
- acrichton
|
||||
- akirilov
|
||||
- avanhattum
|
||||
- bjorn3
|
||||
- bnjbvr
|
||||
- cfallin
|
||||
- fitzgen
|
||||
- jlbirch
|
||||
- sparkerhaynes
|
||||
- uweigand
|
||||
|
||||
### Notes
|
||||
|
||||
- [Regenerating golden output for tests automatically](https://github.com/bytecodealliance/wasmtime/pull/3612)
|
||||
- acrichton: we have manually written tests in clif, using filecheck
|
||||
- requires manual updates everytime there's a large codegen change, e.g. not using FP for leaf functions
|
||||
- the idea: having an env variable that regenerates the golden output for tests on demand
|
||||
- when a large codegen changes happen, run with the env variable set, which regenerates the tests
|
||||
- no effort to update all the tests!
|
||||
- cfallin: likes it: precise compile tests are becoming more rare, we need more execution tests.
|
||||
- akirilov: could have been and be useful for some aarch64 codegen work
|
||||
- uweigand: LLVM has filecheck and a python script that updates the tests automatically like that.
|
||||
- abrown: notes other change made by this PR: change the display of displayed code in the tests by using VCode's `Debug` display
|
||||
- cfallin: in the future, we should prefer run tests (for testing execution), vs precise compile tests ought to be used only for use cases like checking lowering produced the expected patterns
|
||||
- acrichton: should we in a single PR modify all the compile tests to be all precise tests, so they can modified by the tool automatically?
|
||||
- yes
|
||||
- acrichton: as there's no objections, will merge the PR
|
||||
|
||||
# standups
|
||||
|
||||
- alexa: work in progress for verification, Fraser Brown from CMU also interested to join effort.
|
||||
- why are things backwards for the extractor? from "return value" to "arguments"
|
||||
- one reason:
|
||||
- there exist extractors with one return value into multiple values
|
||||
- no multiple values in the lang semantics itself
|
||||
- another reason: some terms can have extractor and constructor
|
||||
- is there a guarantee that vector types in Cranelift are clearly defined? (reliability of types in IR in general)
|
||||
- vec types defined in cranelift are up to 128 bits, no arbitrary width
|
||||
- acrichton: one could use popcnt on f32
|
||||
- cfallin: verifier should be seen as addition to formal verification effort; assume verifier checks code first
|
||||
- fitzgen: more progress on converting x64 ops to isle
|
||||
- acrichton: some x64 conversions too. did test the patch release process this month
|
||||
- abrown: working on migrating select to isle on x64
|
||||
- fitzgen: can land for *some* types even if not all of them are implemented
|
||||
- uweigand: no updates. Will start working on migrating backend to isle.
|
||||
- bnjbvr: no updates.
|
||||
- sparkerhaynes: figuring out variable-width vector. for SVE fixed-width impl, b/o too much ambiguity related to size in the IR.
|
||||
- backend flag to use fixed sizes in the short term, can do better later.
|
||||
- bjorn3: could this be in cranelift-wasm instead of within each backend?
|
||||
- sam: started with accepting a new IR type, instructions will come later
|
||||
- jlbirch: plan to work on ISLE
|
||||
- akirilov: proof of concept for CFI for basic blocks which are targets of indirect branches on aarch64, using the BTI instruction
|
||||
- excluding indirect function calls, as there's pointer auth for those
|
||||
- only *br_table* implementation generates indirect branches
|
||||
- cfallin: any overhead?
|
||||
- anton: runtime hard to measure because BTI not well supported in hardware right now.
|
||||
- empty basic blocks were not materialized because of empty block folding, now every block that's the target of an indirect branch may have BTI instructions at the top => more materialized blocks!
|
||||
- cfallin: have `MachBuffer` emit BTI, or know about BTI which would be "optional" instructions
|
||||
- cfallin: measurements will tell us whether we want to enable this by default, or configuration option. Probably config option.
|
||||
- anton: if BTI instructions are supported by hardware, generate them, otherwise not.
|
||||
- abrown: intel has something similar to BTI, works differently. Requires a kernel that supports Intel CT, compile wasmtime with special support, etc. Is that the case with ARM too?
|
||||
- anton: those instructions become NOPs if not supported by the hardware. Can flag singular memory pages for BTI support when mmapping. It's not mandatory.
|
||||
- abrown: can imagine in the future there's a single flag that is platform independent
|
||||
- anton: challenge with AOT, if generated code has no BTI instructions and it runs on some platforms that enables BTI support for every page by default, will cause runtime exceptions.
|
||||
- cfallin: will require some metadata in addition to the AOT code
|
||||
- akirilov: in general, can we assume that AOT-compiled code runs within the same runtime environment?
|
||||
- acrichton: runtime (Rust) errors when the actual hardware running AOT-compiled code doesn't match such requirements, could use this for BTI.
|
||||
- akirilov: could also use this for large vector support later
|
||||
- cfallin:
|
||||
- Fuzz bug, involving type info lost during regalloc. When emitting moves between values, equivalence classes are created to coalesce moves; an arbitrary class leader is used to get the type and storage size for all vregs in the class. Later when spilling, this size could be smaller than the actual storage of another vreg in same equiv class.
|
||||
- Short term fix: use the largest size that's possible for this reg class. Means wasting some space in some cases (e.g. could allocate 128 bits when spilling f32).
|
||||
- Better fix would be to keep the type information precise, but that's a regalloc invariant we're not maintaining with respect to move instructions. Need to "typecheck" moves and make sure lowerings are correct.
|
||||
@@ -1,136 +0,0 @@
|
||||
# January 24 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. cfallin: 2022 roadmap: thoughts, or merge?
|
||||
- [link](https://github.com/bytecodealliance/rfcs/pull/18)
|
||||
1. cfallin: ISLE migration coordination
|
||||
1. cfallin: platform support tiers; arm32 and updates?
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### 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.
|
||||
@@ -1,64 +0,0 @@
|
||||
# February 7 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
2. avanhatt: ISLE rule verification update/open questions (Alexa, Fraser, Monica).
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
- cfallin
|
||||
- avanhatt
|
||||
- Monica Pardeshi
|
||||
- abrown
|
||||
- bnjbvr
|
||||
- jlbirch
|
||||
- uweigand
|
||||
- sparker-arm
|
||||
- Fraser Brown
|
||||
|
||||
### Notes
|
||||
|
||||
avanhatt presented ISLE SMT rule verification prototype, currently type and term variants for IR-to-IR verification.
|
||||
|
||||
- avanhatt: open question, what should the syntax be? LHS, extractor, is more complex.
|
||||
- cfallin: Feels like global type inference. Annotations on prelude or standard library, keep them out of lowering rules.
|
||||
- avanhatt: Agreed, that it would be good to not have to specify downstream rules.
|
||||
- cfallin: Recursion could be a problem.
|
||||
- uweigand: Not sure I understand the big picture. How do we define formal semantics of backend ISAs?
|
||||
- avanhatt: Current research and tools are available for x86 and Arm.
|
||||
- cfallin: We don't even have a good prose descriptions of CLIF operations yet.
|
||||
- avanhatt: The Alive project managed without formal semantics.
|
||||
- uweigand: Will look to see if there's anything for S390.
|
||||
- uweigand: Could the semantics annotations be used to generate the isel code?
|
||||
- cfallin: Would depend whether it could produce efficient code, would be good for asserts though.
|
||||
- avanhatt: Yes, we could use it for asserts to strengthen fuzzing.
|
||||
- FB: Could be used for equivalence checks on rust code too.
|
||||
|
||||
# standups
|
||||
|
||||
- sparker-arm: Sizeless vector RFC updated, atomics isle porting.
|
||||
- uweigand: Branches and traps lowering changes merged. Implemented atomics, which was complicated for narrow types, involved emitting loops.
|
||||
- sparker-arm: Would the SMT verifier be capable of handling loops?
|
||||
- uweigand: Still not sure to do about call lowering, as calls can return more than two values.
|
||||
- cfallin: Should we do it?
|
||||
- uweigand: S390 ABI wants extended values and isle could be useful for this.
|
||||
- cfallin: Separate call instruction from arg/return setup..?
|
||||
- uweigand: Reorganising ABICaller(Callee?) to simplify the communication between the backend.
|
||||
- uweigand: Next moving onto SIMD.
|
||||
- abrown: ISLE select lowering for x64, seems like more flag handling infrastructure needs to be added. Now looking at sightglass for instantiation metrics.
|
||||
- jlbirch: Worked on a patch for sightglass to automatically trigger benchmarking when a patch is committed. Would like to know why this isn't a good idea for github actions.
|
||||
- cfallin: Need to trust that a PR isn't malicious.
|
||||
- bnjbvr: Has been working on ittapi for cross-platform Vtune support.
|
||||
- abrown: Thanks so much for this.
|
||||
- cfallin: Will be thinking about isle rule precedence.
|
||||
@@ -1,3 +0,0 @@
|
||||
# February 21 project call
|
||||
|
||||
Canceled (US holiday).
|
||||
@@ -1,77 +0,0 @@
|
||||
# March 7 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. Verification annotation syntax (avanhatt)
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
- uweigand
|
||||
- cfallin
|
||||
- avanhatt
|
||||
- abrown
|
||||
- fitzgen
|
||||
- jlbirch
|
||||
- Fraser Brown
|
||||
- bjorn3
|
||||
- bnjbvr
|
||||
- kulakowski-wasm
|
||||
- akirilov
|
||||
- Adrian Sampson
|
||||
|
||||
### Notes
|
||||
|
||||
- Verification annotation syntax (avanhatt)
|
||||
- quick presentation
|
||||
- Syntax proposal for annotations
|
||||
- Comments for individual isle turns
|
||||
- Verification will use annotations if they exist
|
||||
- Can reuse and infer types, or require a new explicit syntax for types and variable bindings
|
||||
- Common assumptions specify return values, more sophisticated ones can handle e.g. failiable operations
|
||||
- Assumptions passed through to the verification IR, which is slightly higher level than SMT per se
|
||||
- fitzgen: Are these always applied to extractors or constructors
|
||||
- avanhatt: Applied to both
|
||||
- cfallin: I would expect it to be the same for extractors or constructors, it aligns with the goals of rewriting engines
|
||||
- fitzgen: Re not repeating ourselves: I think it makes sense to infer types from ISLE parameter types
|
||||
- cfallin: I would refine that and say: 1 place and not 0 places. There should be a declaration somewhere
|
||||
- fitzgen: Right, I think on the type declarations
|
||||
- bjorn3: It would be nice if this was in ISLE instead of comments
|
||||
- avanhatt: At what point do we merge this prototype? Maybe it makes sense then to transition from special comments to real ISLE syntax
|
||||
- cfallin: Feel free to hack up our parser in your branch, and we could take a change for general annotation syntax out of it too.
|
||||
- fitzgen: I dunno how much we want to really copy that, I find it a bit over-engineered. But we could have arbitrary S-expression tags
|
||||
- cfallin: I had a question about fallibility on the conceptual level. Is it that : `assumption` encodes the postcondition if the match succeeds? Or is it encoding the condition for the match to succeed at all? I’d expect the first
|
||||
- avanhatt: Yes, the first.
|
||||
- cfallin: One thing that would be nice to reason about with fallibility is coverage, knowing that our conditions actually cover all cases. Is there a plan to have that?
|
||||
- avanhatt: Set up for it and have talked about it, no actual plan for it. Dovetails with multi rule reasoning
|
||||
- cfallin: Is there a mechanism for abstraction? “Helper functions” for similar operations
|
||||
- avanhatt: Yeah, I think we should. In particular there’s lots of noops. I think we should, but there’s no concrete proposal for it yet.
|
||||
- fitzgen: I think we talked about this on Zulip, but the representation for bitwidth is the same on both left and right hand sides? So we don’t have the ability to represent undefined bits in eg lowering registered width
|
||||
- avanhatt: Would be cool to do, aren’t doing it yet, can extend to do it.
|
||||
- cfallin: Would prefer to not special case things, I’d rather have an S-expression syntax
|
||||
- bjorn3: Also need to think about branches and jumps, take variable amounts of arguments
|
||||
|
||||
- Standups
|
||||
- cfallin
|
||||
- I have been working on ISLE translations. Week before last, was deep in the x64 backend translating arithmetic ops into ISLE. I plan to keep pushing on that when I don’t have other cranelift related tasks as a background thing. I realized that this ISLE translation is not actually on the critical path to regalloc2, as far as I can see: 1 earlier version of regalloc2 which I tried porting Cranelift to only accepted SSA and 2 regalloc2 now has shims for non-ssa code. Can combine with the x64 mov mitosis mechanism for the 2-operand form, and actually land regalloc2 and get rid of lots of movs on the way. Several kilo-lines of code diff, but should be a perf win in compilation time and runtime
|
||||
- uweigand
|
||||
- Merged 2 bits of s390 infrastructure, for variable number of arguments and of return values. Both prereqs for calls and returns, and some other variadic operations. Patch outstanding does now work. Would appreciate feedback on this ISLE-driven approach and where all the knowledge about ABI lives (cfallin will take a closer look soon)
|
||||
- Also looking at SIMD support, and fixing up ABI support for eg callee saved fp-and-vector registers (cfallin: look at aarch64 which has a similar property re clobbers). Also a big discussion on backwards compatible vector register extensions
|
||||
- abrown
|
||||
- Worked on ISLE select lowering, was good and educational. Was going to do integer comparisons and felt it was taking too long around i128. Wondering if we should do it later and focus now on more ordinary register operations.
|
||||
- fitzgen and cfallin: yeah fine as long as we are in working states along the way.
|
||||
- akirilov
|
||||
- Pointer verification (mostly) landed in rust, and I kept working on my proposal to align it with what’s in the rust compiler, and hope to have something to land in the next few days.
|
||||
- jlbirch
|
||||
- Worked on CI integration, acritchon had a bunch of suggestions around ACLs etc.
|
||||
- fitzgen, kulakowski-wasm, Adrian, Fraser, avanhatt, bnjbvr
|
||||
- No other updates
|
||||
@@ -1,40 +0,0 @@
|
||||
# March 21 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. Other agenda items
|
||||
|
||||
|
||||
### Attendees
|
||||
|
||||
Andrew Brown
|
||||
George Kulakowski
|
||||
Sam Parker-Haynes
|
||||
Alexa VanHattum
|
||||
Johnnie Birch
|
||||
bjorn3
|
||||
|
||||
### Notes
|
||||
|
||||
AB: merged several PRs related to x64 ISLE lowering; one of them exposed a regalloc bug during fuzzing, looking into it.
|
||||
|
||||
GK: getting familiar with the Wasm ecosystem (e.g., Cranelift); read Chris' status about the move to regalloc2 (#3942) which, in summary, is progressing but needs some more refactoring before review.
|
||||
|
||||
SP: coming back from vacation, starting to look at aarch64 backend again; continuing work on flexible vectors, working through issues with fully dynamic types in the IR in a way that does not require too many changes to the RFC proposal.
|
||||
|
||||
AV: working on IR for verification, hoping to handle multiple rule chains soon.
|
||||
|
||||
JB: needs to get a patch ready for review; planning to continue ISLE lowering.
|
||||
|
||||
bjorn3: no comments
|
||||
|
||||
SP: with the regalloc2 changes, will we need to make changes to the backends?
|
||||
|
||||
GK: probably not...
|
||||
@@ -1,48 +0,0 @@
|
||||
# April 4 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. Cache for incremental compilation of individual wasm/cranelift functions, brainstorming/design
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
* Benjamin Bouvier (bnjbvr)
|
||||
* Nick Fitzgerald (fitzgen)
|
||||
* Sam Parker (sam)
|
||||
* Anton Kirilov (anton)
|
||||
* Chris Fallin (cfallin)
|
||||
* Alex VanHattum (alexa)
|
||||
* Andrew Brown (andrew)
|
||||
* bjorn3
|
||||
* Johnnie Birch
|
||||
|
||||
### Notes
|
||||
|
||||
* cranelift incremental compilation cache
|
||||
* bnjbvr: once we have already compiled something to machine code, cache the results on disk, if you see the same input again, then reuse the earlier results
|
||||
* bnjbvr: can save compile times for hot reload situations or shared libraries
|
||||
* fitzgen: do you have measurements? I [did some](https://github.com/fitzgen/measure-wasm-dedupe-wins) for different applications with same libraries inside, and they can't share anything if you just look at bytes of function bodies then nothing ends up using the same wasm function indices for calls, etc
|
||||
* bnjbvr: hadn't thought of that, but maybe situation is different for hot reload case
|
||||
* fitzgen: makes sense
|
||||
* cfallin: fitzgen and I had previously talked about canonicalization [missed some bits here...]
|
||||
* cfallin: framework for CLIF
|
||||
* fitzgen: maybe makes sense at wasmtime layer, rather than cranelift, since wasmtime already does caching and rustc already has its own caching, and the runtime/driver will certainly want to control knobs here and limit disk space used for the cache and different embedders might want different knobs
|
||||
* cfallin: think we should build the framework in cranelift but have hooks for embedder to customize as they want
|
||||
* updates
|
||||
* fitzgen: reviewed regalloc2 checker, looking forward to reviewing regalloc2 in cranelift PR
|
||||
* alexa: [there was an update on the ISLE verifier, but I missed it]
|
||||
* sam: working on flexible vectors / dynamic types support for cranelift
|
||||
* anton: updated rfc for pointer auth and BTI, will make a motion to finalize soon
|
||||
* andrew: been porting lowerings to ISLE, working on loads now, moving amode stuff into ISLE
|
||||
* cfallin: regalloc2 in cranelift PR is up, does affect backends a little bit, things are faster in compile time (~20-30% faster) and if the benchmark has register pressure also improves runtime (~20% faster)
|
||||
@@ -1,67 +0,0 @@
|
||||
# April 18 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. Revisit generated-ISLE-code-checked-in? Rebasing pain in PRs (developer
|
||||
experience, CI time) vs. build time impact, and what we could do to mitigate
|
||||
1. Generalized left-hand sides (predicates) in ISLE?
|
||||
1. Plans and timeline for finishing ISLE migration
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
|
||||
* ISLE, checking in code, and rebasing
|
||||
* cfallin: merge conflict any time two PRs change any ISLE at all
|
||||
* cfallin: makes it annoying to rebase, even when you "shouldn't" have to
|
||||
* cfallin: original motivation was to avoid deps for cranelift-codegen to keep build times down and to make the code legible
|
||||
* cfallin: also it is a bit unidiomatic to have generated code checked in, annoying to have to specify a cargo feature to rebuild
|
||||
* cfallin: interested in generating the code again on every build again
|
||||
* abrown: a pro for having it checked in is that during debugging you don't have to figure out which of the various cargo target output directories is the one actually being used to set a breakpoint in
|
||||
* cfallin: we could in the fullness of time make an LSP server..
|
||||
* fitzgen: if we get that far, we've done somethign wrong
|
||||
* cfallin: we could add tracing of which rules/LHSes matched
|
||||
* bjorn3: At least for crates.io releases I really want the generated code to be published. Maybe it could rebuild when using it from git.
|
||||
* bjorn3: The current isle code is much slower than the original meta crate. At least in terms of compile times.
|
||||
* bjorn3: Another thing is that it brings in a lot of dependencies which would all have to be whitelisted in rustc's tidy checker.
|
||||
* avanhattum: can we separate the debuggability of local source from whether the code is checked in or not?
|
||||
* cfallin: maybe a cargo feature for this
|
||||
* abrown: I've also felt the pain of rebase conflicts in ISLE, fwiw
|
||||
* fitzgen: will rebase problems go away after we are done porting instruction selection to ISLE?
|
||||
* cfallin: will be annoying for new contributors, an extra speed bump
|
||||
* avanhattum: can we avoid merge conflicts by generating a more stable output? eg a new rust file for every rule in the extreme
|
||||
* fitzgen: add a cargo flag to include the source position comments, have it off by default
|
||||
* cfallin: yes, we could have a mode for "I'm debugging ISLE source" and a default mode for not
|
||||
* [missed some stuff; talking about adding logging to the generated code]
|
||||
* fitzgen: this should be a cargo feature too since logging is not zero overhead even when disabled
|
||||
* Left-hand sides in ISLE
|
||||
* cfallin: came up when talking with abrown a week or two ago
|
||||
* cfallin: sometimes hard to use extractors to specify what we want
|
||||
* cfallin: case where want to check if two `u32`s can be added and not overflow
|
||||
* cfallin: so we have an extractor with an in-arg, feels very awkward and not like the right solution
|
||||
* cfallin: other pattern matching languages just have top level predicates or conditions
|
||||
* cfallin: combinator for a list of patterns to match instead of a single one
|
||||
* cfallin: would all be rewritten away after the `islec` frontend when translating from `sema` to `ir`
|
||||
* fitzgen: would like to see some examples
|
||||
* ISLE migration
|
||||
* cfallin: how is it going? what timelines do you have? how can we help?
|
||||
* jlbirch: not currently involved, but it is one of our internal goals for the quarter, looking to start contributing soon
|
||||
* abrown: the easy stuff is easy, the hard stuff is not as easy, room for improvement in ISLE syntax (last topic) but also being able to do basic math/arithmetic in ISLE would be nice
|
||||
* abrown: have given up on i128 for now; it is a whole different world
|
||||
* cfallin: going to prioritize meta issues of making ISLE itself better
|
||||
* abrown: afaik cg_clif is the biggest user of i128; do you want to help with migrating the i128 lowerings?
|
||||
* cfallin: also is there a world where cg_clif handles i128 itself? would make it easier for us, but also fine if not; other option is we do this in the mid end
|
||||
* bjorn3: can try helping out with i128 lowerings but not for a little bit
|
||||
* bjorn3: cg_clif can't handle primitive values consisting of multiple Cranelift Value's at the moment. In addition only the backend can do efficient carrying and some ABI's may require Cranelift integration too.
|
||||
@@ -1,3 +0,0 @@
|
||||
# May 2 project call
|
||||
|
||||
Canceled (public holiday)
|
||||
@@ -1,101 +0,0 @@
|
||||
# May 16 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. no announcements
|
||||
1. Other agenda items
|
||||
1. no fixed agenda
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
* Alexa VanHattum (avanhatt)
|
||||
* Andrew Brown (abrown)
|
||||
* Anton Kirilov (akirilov-arm)
|
||||
* Benjamin Bouvier (bnjbvr)
|
||||
* bjorn3
|
||||
* Chris Fallin (cfallin)
|
||||
* Johnnie Birch (jlb6740)
|
||||
* Nick Fitzgerald (fitzgen)
|
||||
* Ulrich Weigand (uweigand)
|
||||
|
||||
### Notes
|
||||
|
||||
* regalloc2 regressions
|
||||
* Ulrich Weigand: rebased the PR migrating call and return instructions to ISLE for s390x
|
||||
* Ulrich Weigand: on top of regalloc2 and noticed regressions in the generated code, i.e.
|
||||
* Ulrich Weigand: lower quality results
|
||||
* Ulrich Weigand: old implementation would move directly into the output register
|
||||
* Ulrich Weigand: the new one creates a new vreg that is aliased to the output register
|
||||
* Chris Fallin: would like to have a look, is there a public branch to check out
|
||||
* Chris Fallin: don't expect extra vregs and moves
|
||||
* Ulrich Weigand: also, the register allocator uses callee-saved registers instead of
|
||||
* Ulrich Weigand: caller-saved ones
|
||||
* Ulrich Weigand: the second issue is that with the previous register allocator there was
|
||||
* Ulrich Weigand: a way to influence the order in which registers are preferred
|
||||
* Ulrich Weigand: s390x uses load and store multiple that accept ranges of registers and that
|
||||
* Ulrich Weigand: become inefficient if successive registers are not used
|
||||
* Chris Fallin: random choice of registers is a deliberate design decision that led to
|
||||
* Chris Fallin: improvements on x86-64; is the issue that non-contiguous ranges are used?
|
||||
* Ulrich Weigand: yes, the code saves and restores unnecessary registers to fill in the gaps
|
||||
* Status updates
|
||||
* Nick Fitzgerald: no Cranelift updates
|
||||
* Chris Fallin: regalloc2 changes, many ISLE-related things - improvements such as if-let,
|
||||
* Chris Fallin: changes to the build system (no checked-in generated source code), various small
|
||||
* Chris Fallin: fixes; the major project right now is working on the middle end, e.g. machine-
|
||||
* Chris Fallin: independent optimizations, starting with alias analysis; the hope is that by
|
||||
* Chris Fallin: using ISLE we will enable interesting optimizations such as fusion, while
|
||||
* Chris Fallin: making verification of the middle end easier
|
||||
* Alexa VanHattum: working on ISLE verification, have a PR not to inline internal constructors,
|
||||
* Alexa VanHattum: also looking into the ISA semantics of Arm and x86 to include one of them
|
||||
* Alexa VanHattum: into the verification process
|
||||
* Benjamin Bouvier: working on the incremental cache idea that has been discussed before, have a
|
||||
* Benjamin Bouvier: heavy use case for hot reload - makes things much faster; the next step is
|
||||
* Benjamin Bouvier: to open a GitHub issue for discussion; the implementation will need a
|
||||
* Benjamin Bouvier: key-value store to keep compilation artifacts
|
||||
* Ulrich Weigand: fixes for ISA feature flag handling and various logic errors in the bitwise
|
||||
* Ulrich Weigand: operation implementations
|
||||
* Andrew Brown: working mostly on the shared linear memory implementation in Wasmtime, which is
|
||||
* Andrew Brown: expected to have some impact on Cranelift
|
||||
* Johnnie Birch: started working with ISLE by implementing square root operations, looking
|
||||
* Johnnie Birch: forward to do more
|
||||
* bjorn3: looking into implementing exception handling (`eh_cleanup` branch on Wasmtime fork),
|
||||
* bjorn3: but a bit stuck at how to deal with caller-saved registers
|
||||
* Anton Kirilov: working on migrating `bitselect`, `vselect` and `splat` to ISLE; after the
|
||||
* Anton Kirilov: associated RFC has been accepted, has finalized the forward-edge CFI
|
||||
* Anton Kirilov: implementation, which is now ready for review
|
||||
* sightglass discussion
|
||||
* Andrew Brown: Docker had been introduced to sightglass to facilitate reproducible builds
|
||||
* Andrew Brown: recently a PR on the handling of build metadata that failed CI testing led to
|
||||
* Andrew Brown: the idea of getting rid of Docker
|
||||
* Nick Fitzgerald: Docker is frequently a source of inconvenience
|
||||
* Chris Fallin: Docker is also Linux-specific, which might be a problem in the future if we
|
||||
* Chris Fallin: decide to support other platforms
|
||||
* Johnnie Birch: another problematic use case - internal framework to run stuff everywhere, e.g.
|
||||
* Johnnie Birch: in the cloud; it uses Docker within Docker, which has also caused trouble
|
||||
* Andrew Brown: so let's remove Docker, but would be the replacement - something to encode a
|
||||
* Andrew Brown: sequence of commands in an OS-agnostic way?
|
||||
* Chris Fallin: what are we using Docker exactly for?
|
||||
* Andrew Brown: cloning repositories and `cargo build`, but there are knobs for configuratrion
|
||||
* Andrew Brown: parameters, so that it is possible to use your repository, for example
|
||||
* Nick Fitzgerald: there are so many different ways to build something, so we should push back
|
||||
* Nick Fitzgerald: on supporting everything, just the things we really need
|
||||
* Nick Fitzgerald: How many knobs are there? If it is just a commit ID, then it is fine, but
|
||||
* Nick Fitzgerald: adding support for more than that might open a can of worms
|
||||
* Andrew Brown: repository location, commit ID, build flags
|
||||
* Nick Fitzgerald: other engines have other settings - Make flags, `configure` flags, etc.
|
||||
* Chris Fallin: environment variables as well
|
||||
* Nick Fitzgerald: is there a use case for using non-default build flags?
|
||||
* Andrew Brown: it is not huge
|
||||
* Nick Fitzgerald: the feeling is that sightglass should be simpler than it is right now
|
||||
* Nick Fitzgerald: currently we usually compare either two branches or compare commits over time
|
||||
* Nick Fitzgerald: on the other hand, we should record enough metadata, so that a suitably
|
||||
* Nick Fitzgerald: motivated individual could reproduce the environment manually
|
||||
@@ -1,85 +0,0 @@
|
||||
# June 6 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
- abrown
|
||||
- akirilov
|
||||
- avanhattum
|
||||
- cfallin
|
||||
- fitzgen
|
||||
- sparkerhaynes
|
||||
|
||||
### Notes
|
||||
|
||||
- ISLE porting status and plans?
|
||||
- abrown: Quarterly goals at Intel, port a number of instructions over to ISLE.
|
||||
- Want to continue doing so.
|
||||
- Issue is that all the hard ones are left.
|
||||
- We need more people to look at it.
|
||||
- akirilov: Quarterly basis too.
|
||||
- Our approach was different, we've gone for the harder ones first.
|
||||
- Trying to improve test coverage.
|
||||
- abrown: How are you guys tracking coverage?
|
||||
- akirilov: It's just manual, the bar is currently quite low so easy to see where they're missing.
|
||||
- Interpreter has failed to handle some cases, something to do with splat.
|
||||
- Some run tests don't check the return values.
|
||||
- Sometimes disabling the interpreter tests.
|
||||
- cfallin: Sounds like the right approach.
|
||||
- abrown: What's the state of SIMD interpreter support? afonso was working on it.
|
||||
- cfallin: Don't know what happened to afonso, work has stalled on it.
|
||||
|
||||
- akirilov: Regalloc2 limitation of only 2 reg classes
|
||||
- SVE will need a predicate file, same for AVX-512.
|
||||
- cfallin: Bit packing issue, could remove the 'mod' operands and reuse that bit.
|
||||
- akirilov: Will four classes be enough..? It is probably fine for AArch64.
|
||||
- cfallin: Will keep this on my back burner.
|
||||
|
||||
# standups
|
||||
|
||||
- fitzgen: No updates.
|
||||
|
||||
- avanhattum: Better semantics for verification.
|
||||
- SAIL for x64 and arm.
|
||||
- Figuring out what work is needed to use modern SAIL for x64.
|
||||
- Working on shim code to avoid annoting machine instructions.
|
||||
|
||||
- akirilov: cranelift CFI patch updates and Fiber changes for MacOS.
|
||||
- bjorn3 gave feedback and noticed codegen wasn't right.
|
||||
- some branches were elided and the branch target instructions ended up as the last instruction, not first.
|
||||
- pointer authentication is still disabled in qemu.
|
||||
|
||||
- cfallin: Implemented alias analysis for load elimination, with okay speedups.
|
||||
- could have benefitted some option optimizations, such as GVN
|
||||
- So developing a unified framework for rewrite rules in the mid-end.
|
||||
- egraphs seem the right approach.
|
||||
- need an adapter to convert the egraph to LowerCtx: clif -> egraph -> vcode
|
||||
- Then need to figure out isle rewrite rules.
|
||||
- Framework will subsume all the existing mid-end optimisations.
|
||||
- Also worked on a fix regalloc2 issue, reducing stack size usage.
|
||||
- alexa: static rewrite rules or equality saturation?
|
||||
- chris: equality.
|
||||
|
||||
- abrown: shared memory in wasmtime.
|
||||
- impacts cranelift through `memory_size` instruction.
|
||||
- How are we gonna test this? Looking for ideas and feedback.
|
||||
- Ported some atomic operations for x64, not sure CAS is right.
|
||||
|
||||
- sparker: Dynamic vector RFC is up in code form.
|
||||
- It's a bit rough and would greatly appreciate some feedback.
|
||||
- cfallin: does qemu support sve?
|
||||
- sparker: yes.
|
||||
@@ -1,76 +0,0 @@
|
||||
# June 13 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. bnjbvr: Maintainance and code ownership of cranelift-jit-demo (e.g. [this PR](https://github.com/bytecodealliance/cranelift-jit-demo/pull/66))
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
- abrown
|
||||
- akirilov
|
||||
- avanhatt
|
||||
- bjorn3
|
||||
- bnjbvr
|
||||
- cfallin
|
||||
- fitzgen
|
||||
- jlbirch
|
||||
- sparker-arm
|
||||
|
||||
### Notes
|
||||
|
||||
Agenda item:
|
||||
|
||||
- bnjbvr: who owns the cranelift-jit-demo repo? is it collective responsibility? meta
|
||||
question: how do we decide that in general?
|
||||
- cfallin: meta question, probably a bytecode alliance thingy, RFC to discuss.
|
||||
For this particular repo, would github's CODEOWNERS work?
|
||||
- bnjbvr: explains how CODEOWNERS works. Not a solution for merge right. Github
|
||||
has different allowance access for individuals, so could give merge rights to
|
||||
a specific individual.
|
||||
- cfallin: either open an RFC, or discuss this at next wasmtime meeting
|
||||
|
||||
Updates:
|
||||
|
||||
- sparker-arm: aarch64 vector work, benchmarking, moving along well, no PR opened yet
|
||||
- cfallin: worked with egraph, subsumes GVN now, LICM soon. Question is how
|
||||
does the rewrite system look like? Now that something works, write up an RFC
|
||||
and see what people think.
|
||||
- avanhatt: lots of verification updates, half way reviewing egraph PR
|
||||
- bnjbvr: work paused the last two weeks on incremental cache, back to it this week
|
||||
- akirilov: PAC (pointer authentication) work in fiber has been merged, CI uses PAC now, RFC + patch to
|
||||
be updated soon
|
||||
- cfallin: that's on linux aarch64, how far are we from enabling for mac
|
||||
m1?
|
||||
- akirilov: codegen changes was easy, unwinding harder, not sure about
|
||||
the complexity for mac m1.
|
||||
- bjorn3: mac m1's ABI is slightly different from linux aarch64's one
|
||||
- jlbirch: talked about security concerns with Alex re: sightglass /
|
||||
benchmarking.
|
||||
- cfallin: how will this work? bot? manual trigger?
|
||||
- jlbirch: anyone with sufficient permissions can comment/open issue to run
|
||||
a workflow run (repository dispatch event), private repo will run the
|
||||
PRs, do the testing and send the results back to the PR/issue. This will
|
||||
be running on private machines (linux x64, linux aarch64).
|
||||
- sparker-arm: limit egraph optimizations, how does it work?
|
||||
- cfallin: fuel mechanism to limit # (number of) rules of application, metric on
|
||||
memory usage (# nodes, classes), hard cap this to some multiple of #
|
||||
cranelift input nodes.
|
||||
- sparker-arm: (*notetaker missed that question*)
|
||||
- cfallin: no rewrites at all at the moment, just hash-const. Turn up knob to
|
||||
get several optimization rounds.
|
||||
- avanhatt: would we do inter-procedural analysis in the future? ie allow
|
||||
rules to rewrite across function boundaries somehow?
|
||||
- cfallin: prob not. Could blow up memory/time, so we'd need to explore.
|
||||
We'd do that only if we inlined that callsite already (so not across
|
||||
function boundaries)
|
||||
@@ -1,63 +0,0 @@
|
||||
# June 27 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
### Attendees
|
||||
|
||||
- abrown
|
||||
- cfallin
|
||||
- fitzgen
|
||||
- afonso360
|
||||
- akirilov-arm
|
||||
- bjorn3
|
||||
- Jamey Sharp
|
||||
- jlbirch6740
|
||||
- uweigand
|
||||
|
||||
### Notes
|
||||
|
||||
No published agenda, proceeding to status updates:
|
||||
|
||||
fitzgen: have been looking into stack walking; will eventually look into
|
||||
unwinding as a part of exception handling; sync up with bjorn3 to row in the same
|
||||
direction
|
||||
|
||||
afonso360: (welcome back!) have continued work on Cranelift interpreter,
|
||||
starting to figure out ISLE, posted several aarch64 patches
|
||||
|
||||
uweigand: out on vacation, upstreamed some changes to QEMU to fix breakage with
|
||||
Wasmtime in v7.0 (fix is in 7.1); also, merging a change to add a "build
|
||||
Wasmtime regression test" to QEMU's CI; planning on moving to vector
|
||||
registers/instructions in s390x backend
|
||||
|
||||
bjorn3: no updates
|
||||
|
||||
Jamey Sharp: listening in, no updates
|
||||
|
||||
akirilov: CFI final version is up for review--feedback needed; started porting
|
||||
splat to ISLE for aarch64
|
||||
|
||||
abrown: some sightglass investigation with Yury (performance analysis Chris
|
||||
might be interested in); continued shared memory changes in Wasmtime
|
||||
|
||||
jlbirch6740: discussed benchmarking infrastructure for CI with fitzgen and
|
||||
abrown, still need to publish PR; submitted a PR to fix a profiling flag in the
|
||||
C API
|
||||
|
||||
cfallin: out sick, investigated performance problem re: splitting in regalloc2
|
||||
brought by alexcrichton, want to review and merge before next release; also is
|
||||
investigating a regalloc2 checker violation reported by bjorn3 re: pinned vregs
|
||||
(high priority fix!); eventual plan would be to kill pinned vregs and use
|
||||
operands with constraints instead; finishing up e-graphs RFC (will post an
|
||||
initial PR soon)
|
||||
@@ -1,21 +0,0 @@
|
||||
# July 11 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. [E-graph-based mid-end optimization](https://github.com/bytecodealliance/rfcs/pull/27)
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# July 25 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# August 8 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# August 22 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# September 12 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# September 19 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# October 3 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# October 17 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# October 31 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# November 14 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# November 28 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# December 12 project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,21 +0,0 @@
|
||||
# Cranelift project meetings
|
||||
|
||||
The Cranelift project holds bi-weekly meetings, and we welcome all interested parties to join.
|
||||
|
||||
## Time and location
|
||||
|
||||
**When**: every second Monday at 3:30pm UTC during US DST / 4:30pm UTC otherwise
|
||||
**Where**: Zoom (link in calendar invite)
|
||||
|
||||
|
||||
## Attending
|
||||
|
||||
To attend, please email <cfallin@fastly.com>, or reach out [on Zulip](https://bytecodealliance.zulipchat.com/#narrow/stream/217117-cranelift).
|
||||
|
||||
## Agendas and notes
|
||||
|
||||
Both agendas for upcoming and notes for past meetings will be posted in subdirectories for each year.
|
||||
|
||||
## Adding agenda items
|
||||
|
||||
To add something to the agenda for an upcoming meeting, open a pull request to modify the agenda.
|
||||
@@ -1,71 +0,0 @@
|
||||
# August 5 Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
- Alex: update on Wasm64
|
||||
- Andrew: update on differential fuzzing against spec interpreter
|
||||
- Till: meetings are finally public
|
||||
- Chris: SIMD complete on x64 and aarch64
|
||||
|
||||
## Attendees
|
||||
- Alex
|
||||
- Andrew
|
||||
- Benjamin
|
||||
- Chris
|
||||
- Dan
|
||||
- Johnnie
|
||||
- Nick
|
||||
- Pat
|
||||
- Till
|
||||
|
||||
## Notes
|
||||
### Wasmtime project meetings public
|
||||
Till: We now invite the public to join this meeting.
|
||||
Alex: Should we record these meetings?
|
||||
Various: It’s a tradeoff, but recording meetings has the downside of making people less open, so it seems like we’ll continue to not record them for now.
|
||||
|
||||
### Wasm64 support
|
||||
Alex: I’m implementing wasm64 in Cranelift.
|
||||
Initial focus is on getting it working; optimization will happen later.
|
||||
PR is almost ready; currently doing fuzzing and fixing bugs
|
||||
Initial implementation will bounds-check on every access
|
||||
Andrew: Is there a way to use guard pages?
|
||||
CF: Could we do pointer masking?
|
||||
Alex: Wasm semantics need a bounds check.
|
||||
Alex: Our focus right now is just to make sure all our infrastructure is in place for 64-bit addresses. We’ll look at optimization later, and hopefully the people championing wasm64 will help come up with ideas in this space.
|
||||
Alex: It will also help once we have benchmarks to help us evaluate performance.
|
||||
Alex: In some settings we may be able to specialize for the case where the memory is dynamically always less than 4 GIB.
|
||||
Till: If wasm64 becomes popular, people may start asking about ASLR. There’s a lot to think about here?
|
||||
Dan: Hardware support could significantly accelerate wasm64 and give us more options for things like ASLR.
|
||||
Till: There are actual use cases for wasm64 out there.
|
||||
|
||||
### Differential fuzzing against spec interpreter
|
||||
Andrew: Wasm spec interpreter and fuzzing.
|
||||
Fuzzing against the spec interpreter would be nice because we’d be able to compare wasmtime to the spec interpreter. The spec interpreter is written in OCaml, so I’m using the OCaml API to run the spec interpreter.
|
||||
It’s only scalar for now, but we’ll add SIMD, which will be one of the big motivations for this work.
|
||||
Requires having OCaml installed on the system.
|
||||
Instrumentation indicates that about half of the fuzz-generated modules are actually getting executed, so it seems like it’s working pretty well.
|
||||
There’s currently an unexplained segfault.
|
||||
Some work items remaining to enable SIMD:
|
||||
Enable wasm-smith to emit SIMD code
|
||||
Either use git tricks to use the simd proposal repo, or wait for simd to merge to the spec repo
|
||||
|
||||
### SIMD support complete
|
||||
Chris: Wasm SIMD support is now complete, big thanks to Andrew and Johnnie, and Anton and
|
||||
Enable it with a command-line flag. One more PR needed for arm64 support.
|
||||
Getting ready to announce it publicly; need more testing, and possibly the OCaml fuzzing work before enabling it by default
|
||||
Alex: One way to test is to compile misc Rust crates with autovectorization.
|
||||
Chris: The fuzzer would be the big thing to aim for.
|
||||
|
||||
### [ad-hoc item] Project positioning
|
||||
Benjamin: What is the project positioning about?
|
||||
Chris: We’re starting to put together an RFC.
|
||||
Till: As the project grows, we need to communicate shared goals.
|
||||
Johnnie: Have there been any specific problems related to this?
|
||||
TIll: No, but this is something we see across many projects, where individuals and organizations will go off and add features or make changes that meet their needs, and it can be difficult to integrate them into a coherent whole if we don’t have well-communicated shared goals.
|
||||
|
||||
### [ad-hoc item] Status of replacing Lucet with Wasmtime?
|
||||
Andrew: What is the status of replacing Lucet with Wasmtime?
|
||||
Pat: We’ve made lots of progress, can serialize/deseriealize, though it’s still months out from production use. Wasmtime has all the features.
|
||||
Till: And we know know of another Lucet user that has switched to Wasmtime.
|
||||
@@ -1,22 +0,0 @@
|
||||
# August 19 Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Sumbit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. Wasmtime's new `cranelift` compile-time feature (Alex, 5 min)
|
||||
2. [Wasmtime 1.0](https://github.com/bytecodealliance/rfcs/pull/14) (Alex, 15-20 min)
|
||||
3. _Sumbit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,90 +0,0 @@
|
||||
# September 02 Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Sumbit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. Improvements to precompiled module load times (Alex, 5-10 min)
|
||||
1. _Sumbit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
- Nick Fitzgerald (NF)
|
||||
- Alex Crichton (AC)
|
||||
- Benjamin Bouvier (BB)
|
||||
- Till Schneidereit (TS)
|
||||
- Pat Hickey (PH)
|
||||
- Chris Fallin (CF)
|
||||
- Andrew Brown (AB)
|
||||
- Johnnie L Birch (JB)
|
||||
- Dan Gohman (DG)
|
||||
- Will Woods (WW)
|
||||
|
||||
### Notes
|
||||
|
||||
- NF: heads-up: intern from KTH to work on wasm-mutate
|
||||
- take a wasm binary, parse it, make some transformation (optionally
|
||||
semantics-preserving). Will help fuzzing.
|
||||
- AB: will be on sabbatical for two months (starting in 10 days)
|
||||
- all: have fun!
|
||||
- AC: improvements to module load time
|
||||
- https://github.com/bytecodealliance/wasmtime/issues/3230#issuecomment-910528582
|
||||
- Making loading precompiled modules fast. Now basically `mmap` and run.
|
||||
About 100x faster.
|
||||
- Precompiled modules are now valid ELF modules. Allows `objdump -d` to look
|
||||
at compiled output code.
|
||||
- TS: new API to make this work?
|
||||
- AC: currently "deserialize a module from these bytes"; now also have
|
||||
"deserialize a module from this file" to allow mmap. Might add other
|
||||
flavors as well for other use-cases.
|
||||
- JB: Ready to use now? (AC: yes!) Better alternative to `wasm2obj`?
|
||||
- AC: wasm2obj is still there; but we can now do `wasmtime compile` and
|
||||
disassemble the resulting ELF. This means we see the exact code whereas
|
||||
`wasm2obj` sometimes diverged in settings.
|
||||
- TS: this was one of the big remaining things where we knew there's work to
|
||||
do; now it's done!
|
||||
- TS: no full numbers yet to compare against Lucet but if the measurements
|
||||
scale up this should be faster than Lucet. wasmtime was originally 20x
|
||||
slower. Lucet does dlopen; dlopen needs to do more relocations.
|
||||
- AC: one day would be nice to be able to statically link a compiled Wasm
|
||||
module into your application. RLBox-style. Not quite there yet.
|
||||
- TS: talked to RLBox a while ago, seemed clear wasmtime wasn't right for
|
||||
RLBox at the time because of compilation strategy and also call overhead.
|
||||
Taking a look at call overhead now (wasm->host, host->wasm) especially
|
||||
for non-Rust embeddings.
|
||||
- TS: using direct calls -- makes things faster?
|
||||
- AC: probably!
|
||||
- CF: spectre mitigations disable indirect predictor entirely or partly (?)
|
||||
so indirect calls are somewhat expensive; this should be better
|
||||
- TS: think that maybe we did direct calls before but maybe not?
|
||||
- CF: we just did an Abs8 constant loaded into a register, to avoid
|
||||
problems with range
|
||||
- CF: relevant on aarch64, part of Alex's patch was careful work to make
|
||||
long-range (> 64MiB on aarch64) calls work. Still an issue with
|
||||
intra-function branches but that issue was there before; other limits
|
||||
come into play as well.
|
||||
- AC: yes, e.g. regalloc limits.
|
||||
- CF: scaling up to large code and hitting implementation limits is a
|
||||
bigger issue that we should definitely address
|
||||
|
||||
- TS: APIs; stable C API, unstable C++ API on top of it, call performance
|
||||
- supporting calls into native C-ABI functions; more difficult than in Rust
|
||||
where we can monomorphize around the function we're given
|
||||
- AC: not sure if this will pan out. Would involve JIT compilation between
|
||||
wasmtime-defined layers and outside world.
|
||||
- DS: impossible to expose wasm functions as C-ABI function pointer?
|
||||
- AC: lots of stuff to set up, like setjmp, etc
|
||||
- AC: call overhead Rust to wasm is ~20ns, C overhead is ~30ns, both with no
|
||||
args, higher with args
|
||||
- TS: all runtimes are slow enough that this doesn't stick out; in other
|
||||
runtimes calls have to go through JS
|
||||
- AC: want to get at least wasm to host overhead as low as possible
|
||||
@@ -1,98 +0,0 @@
|
||||
# September 16 Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Sumbit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Sumbit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
* No agenda, but a few things that would be useful maybe:
|
||||
* Wasmtime 1.0 rfc
|
||||
* C API function call improvements
|
||||
* CI for arm, and in particular M1
|
||||
* Alex: 1.0 rfc is now in FCP
|
||||
* Main change is that we’ve dropped LTS releases since no one is asking for it
|
||||
* Releases every 4 weeks
|
||||
* CVEs/bugs will backport to the current release
|
||||
* If in the future we decide to add LTS, then we will be more informed
|
||||
* Backports should be relatively easy since they’re only a month old
|
||||
* Till: should we backport CVEs to at least two releases?
|
||||
* Alex: we guarantee one release, but can do more at our discretion
|
||||
* Till: because the rfc entered FCP, it will likely merge in ten days
|
||||
* We don’t have a timeline for when we actually do the 1.0 release yet and all the automation around releases
|
||||
* Alex: excited to remove lightbeam
|
||||
* Till: also old backend is something we should discuss
|
||||
* It has recently been a maintenance burden, would like not to have that burden, but this requires more discussion
|
||||
* In particular Ben previously mentioned better compile times on embark’s code base with the old backend
|
||||
* Ben: we are actually using the new backend now, but are concerned with compile times
|
||||
* Till: previously mentioned that you were developing with the old backend but releasing with the new, is that still the case?
|
||||
* Ben: no, we have switched over to the new backend
|
||||
* Till: might actually not be any old backend users anymore then
|
||||
* Alex: update on the C API and function calls
|
||||
* Has been fast in rust for a while
|
||||
* C was going through the dynamically checked slow path
|
||||
* Motivation: 2 ns to enter/leave in rust vs some number in the hundreds for C
|
||||
* Exposed the `*mut 128` buffer where args/rets are written/read to C directly
|
||||
* C++ will do the same safety encapsulation that Rust has
|
||||
* C doesn’t have these abstraction capabilities, so will always be unchecked and unsafe
|
||||
* Now got C down to 10 ns, which is a lot better
|
||||
* But there is no inlining (without cross language LTO) which accounts for a lot of the remaining delta
|
||||
* There are more possibilities for speed ups here, but is getting harder to maintain and diminishing returns
|
||||
* Think this is good for now and we can revisit again if necessary
|
||||
* Till: one thing about the C API is that using it requires cranelift to be available, unlike when using the rust crate, where you can disable the compiler and only execute precompiled modules, not compile new modules
|
||||
* This is something we could fix for the C API but could be a bit more involved
|
||||
* Something for the future if someone is motivated
|
||||
* Till: let’s talk about M1 builds
|
||||
* Anton: my worry is that we might miss something with qemu
|
||||
* Yesterday an OOM test merged but is disabled under qemu
|
||||
* Fragile, saw this test start failing when running the test natively
|
||||
* When I run it solo, it passes, but as part of the whole test suite it fails
|
||||
* Point is: we can miss issues when only using qemu and/or disabling tests under qemu
|
||||
* This was on aarch64 in general not M1, fwiw
|
||||
* Alex: is this the test that allocates a bunch of random stuff?
|
||||
* We’ve had to disable these tests before because qemu has issues with virtual memory and eagerly committing it [or something like that]
|
||||
* Try limiting parallelism to cut down on memory overhead
|
||||
* Hard to consider aarch64 truly tier 1 until we are testing it natively on CI
|
||||
* Till: do we know if there is any progress on having arm-based runners in github actions ci?
|
||||
* Rustc did it but is bespoke and has a huge amount of work that went into it to make it safe to run random PRs
|
||||
* Alex: best thing I can think of for testing aarch64 in ci would be to have daily builds without cfg’ing things on/off but just let it break and give a notification
|
||||
* Easier to fix, generally, when it is a recent regression
|
||||
* Ben: embark has such a thing, can add other people to the email notifications
|
||||
* Alex: out of curiosity would it be easy to [something I didn’t catch]
|
||||
* Ben: can ask
|
||||
* Till: can we have self-hosted runners that don’t run automatically, but only for trusted folks who have commit access to the repo anyways? Maybe with a button that needs to be pushed?
|
||||
* Alex: would be great, but is a lot of infra to build. Need tests running daily at least, maybe not necessarily every PR
|
||||
* Till: get them running is step one, policy for fixes/backouts/etc is step two, who is responsible for being on the hook for regressions, etc
|
||||
* Alex: we will still run qemu in our CI, so hopefully this is just for the few bugs where that is different between qemu and native
|
||||
* Till: do we need to build this infra ourselves or has anyone made off the shelf solutions we can set up?
|
||||
* Alex: I think this is mostly something we would have to set up
|
||||
* Till: unlikely that this is on the critical path for fastly, but if other people build the CI we can accept that as part of the common maintenance burden that contributing anything to wasmtime carries
|
||||
* Anton: maybe we can start with just nightly builds before CI
|
||||
* Alex: i was kind of hoping that we could take the existing nightly M1 builds that embark is doing and add the config to integrate with our CI
|
||||
* Ben: will see if we can give more access to trusted BA members
|
||||
* We don’t have linux aarch64 tho
|
||||
* Alex: we have a linux aarch64 machine available, we just need to connect this with your existing CI set up
|
||||
* Ben: our build kite set up is protected behind our firewall
|
||||
* Alex: we could also have another build kite account, but just want to reuse config so we don’t have to figure it all out ourselves
|
||||
* Anton: M1 is aarch64-based but linux and macos are not the same
|
||||
* Memory page sizes differ
|
||||
* Shouldn’t lump them together
|
||||
* Alex: yes, more testing is better if we can get it
|
||||
* Till: github actions runner went from pre-release to official release for aarch64 in june [or something]
|
||||
* Maybe we can get some info from github on timing for native github aarch64 runners
|
||||
* And then maybe we won’t need to build this infra ourselves
|
||||
* Although they don’t have M1 releases
|
||||
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# September 30 Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Sumbit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Sumbit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,22 +0,0 @@
|
||||
# October 14 Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Sumbit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Sumbit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
|
||||
*No agenda; meeting called after a few minutes.*
|
||||
@@ -1,81 +0,0 @@
|
||||
# October 28 Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Sumbit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. Discuss [Wasm exception handling](https://github.com/WebAssembly/exception-handling)
|
||||
implementation strategy (see
|
||||
[#3427](https://github.com/bytecodealliance/wasmtime/issues/3427)).
|
||||
1. New release process and making an 0.31 release (@alexcrichton).
|
||||
1. _Sumbit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
* Fitzgen
|
||||
* Cfallin
|
||||
* Bjorn3
|
||||
* Catherine z
|
||||
* Dgohman
|
||||
* Alex crichton
|
||||
* Bnjbvr
|
||||
* Anton kirlov
|
||||
|
||||
### Notes
|
||||
|
||||
* Wasm EH strategy
|
||||
* Root of decision tree: How do we build support for unwinding? Options:
|
||||
* Generate EH tables in DWARF and SEH
|
||||
* Pro: ABI compat with other compilers
|
||||
* Con: More effort
|
||||
* Generate a custom format
|
||||
* Pro: we’d control it; no dependency on libunwund
|
||||
* Nick: in GC and reference-types, we’re using libunwind already, though historically we’ve wanted to change this, as libunwind is slow and unreliable.
|
||||
* Chris: It seems like if we do a custom format for EH, it makes sense to use it for GC and reference-types too.
|
||||
* Catherine z: Regardless of the strategy, a lot of the infrastructure can be shared.
|
||||
* Catherine z: Other consumers, such as debuggers and other tools, only support DWARF
|
||||
* Chris: Another option would be to support all of the above, DWARF, SEH, and our own format.
|
||||
* Alex: We can keep clif IR simple, because we don’t need the full DWARF expressivity.
|
||||
* Alex: We might start with our own subset of DWARF and use that.
|
||||
* Bjorn3: I built a prototype of https://hackmd.io/@bjorn3/r1kCYBuIt a https://github.com/bytecodealliance/wasmtime/compare/main...bjorn3:eh_cleanup which may be a starting point.
|
||||
* Alex: DWARF also gives us dwarfdump and objdump compatibility
|
||||
* Nick: That’s been really helpful.
|
||||
* Chris: Starting with DWARF sounds good, though we should look closely at SEH to make sure we don’t become accidentally incompatible with it.
|
||||
* Anton: If we use DWARF, we get compatibility with the system unwinder.
|
||||
* Alex: I expect we’re not going to build our own full DWARF and SEH unwinder; starting with our DWARF subset, we can just implement our own simple unwinder that just does the parts we want, and we can use it on Windows as well.
|
||||
* Chris: I envision two RFCs coming out of this: one for the CLIF IR, and one for the output format.
|
||||
* Alex: We might be ok with just one RFC.
|
||||
* Alex: I consider zero-cost a requirement.
|
||||
* Release process and the 0.31 release.
|
||||
* Alex: Lots of automation, for releases and publishing packages.
|
||||
* Nick: Are we going to have a canary release?
|
||||
* Alex: Yes, and we should have some extra documentation around a 1.0 release.
|
||||
* I’d like to trial the new release process with a 0.31 release.
|
||||
* Chris: do we have docs for the release process, and for the manual version of the release process when the automatic process fails?
|
||||
* Alex: Yes and yes. Some parts may still be in my head, so I’m happy to document more things as we find things missing.
|
||||
* Johnny: We were experimenting with wasm64, and we aren’t seeing any performance difference. Does anyone have any advice on what tools to use?
|
||||
* Alex: clang/llvm have basic wasm64 support, though Rust and wasi-sdk don’t fully support it yet.
|
||||
* Johnnie: no initial perf diff with the things we have tested, haven’t looked at perf counters in too much detail, just timings
|
||||
* Cfallin: make sure you are comparing against wasm32 without bounds checks (also with bounds checks, I guess)
|
||||
* Alex: worth double checking if you are actually using wasm64. Dan, does wasi-sdk have plans for wasm64?
|
||||
* Dan: [missed the answer]
|
||||
* Anton: could we make wasm64’s bounds checks branchless with cmov where we make pointers null that are out of bounds and then keep using signal handlers?
|
||||
* Alex: we would have to be careful to deal with offsets correctly
|
||||
* Anton: did some small benchmarks with V8 vs Wasmtime on aarch64, Wasmtime was actually faster on my workloads, it seems like they aren’t using virtual memory tricks for bounds checking, at least on aarch64. On aarch64 explicit bounds checks have ~10% overhead.
|
||||
* Alex: we haven’t put a ton of work into optimizing bounds checks or doing redundant bounds checks elimination in cranelift
|
||||
* Anton: could possibly use memory tagging for bounds checking in wasm64 on aarch64
|
||||
* Cfallin: would be interesting to see some experiments/benchmarks, are cores with this available?
|
||||
* Anton: should be available on the market in the next half year or so probably (just a guess)
|
||||
* Dan: using mpk is hard because we need to interleave stack storage and the wasm memory region
|
||||
* Dan: could have a separate `mmap` of the memory [missed the details for the rest]
|
||||
* Anton: that sounds similar to what address sanitizer does
|
||||
* Anton: RFC for CFI enhancements is posted; feedback welcome.
|
||||
@@ -1,69 +0,0 @@
|
||||
# November 11 Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Sumbit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Sumbit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
- WGR
|
||||
- cfallin
|
||||
- acrichton
|
||||
- tschneidereit
|
||||
- bjorn3
|
||||
- abrown
|
||||
- fitzgen
|
||||
- Will W
|
||||
- jlbirch
|
||||
|
||||
### Notes
|
||||
|
||||
* Till: milestone to report: Fastly recently hit 1 trillion Wasm instantiations; no
|
||||
operational issues at scale (using Lucet with Cranelift)
|
||||
- Close to switching over to Wasmtime
|
||||
- Results from security assessment on integration of Wasmtime with Fastly's
|
||||
environment; no issues found
|
||||
|
||||
- jlbirch: how will the switchover work?
|
||||
- Till: Not a prolonged period with two separate runtimes
|
||||
- Till: will update the group here once it's in production! In testing, we're
|
||||
seeing significant performance gains, excited and optimistic.
|
||||
|
||||
* Till: looking at optimizing the Python embedding, more info soon
|
||||
|
||||
* abrown: back after two months (welcome!), what are we excited about and
|
||||
looking forward to in the near future?
|
||||
- Till: Alex put together release infra (automated), RFC for 1.0 release.
|
||||
- before we do this, maybe a once-over on the documentation would be good
|
||||
- also planning around announcement/publicity
|
||||
- Till: Fastly has an intern working on wasm-mutate
|
||||
- fitzgen: this is for fuzzing; taking a valid Wasm module and tweaking it
|
||||
in some way to generate another case, for custom mutator hook
|
||||
- cfallin: ISLE DSL in Cranelift
|
||||
- WASI: adopted new format for the IDL, renamed it from witx. Better, more
|
||||
approachable developer experience. Dan working on applying all of this to
|
||||
wasi-libc, wasi-sdk, to make sure we have everything needed.
|
||||
|
||||
- Till: fuzzing?
|
||||
- Alex: SIMD disabled until fuzzbugs fixed
|
||||
- spec interpreter fuzzing disabled for now due to timeouts
|
||||
- V8 differential fuzzing
|
||||
- cfallin: alternate way of using spec interpeter for individual
|
||||
instruction semantics possible
|
||||
- Till: would be good to take stock of SIMD status eventually and see if we
|
||||
might want to enable it
|
||||
- Andrew: relaxed SIMD, flexible vectors?
|
||||
- Alex: relaxed SIMD parsing from Yury at Mozilla
|
||||
- cfallin: flexible vectors in progress by Sam Parker at ARM
|
||||
|
||||
@@ -1,20 +0,0 @@
|
||||
# November 25 Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Sumbit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Sumbit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,24 +0,0 @@
|
||||
# December 9 Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. Profiling (with vtune on Linux and Windows, other profilers on Windows, profiling on MacOS)
|
||||
2. Benchmarking infrastructure
|
||||
3. Feature: Incremental compilation cache (function granularity)
|
||||
4. Feature: CPU intrinsics
|
||||
5. Feature: read-only wasm memories
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,41 +0,0 @@
|
||||
# January 6th Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
- abrown
|
||||
- fitzgen
|
||||
- acrichton
|
||||
- cfallin
|
||||
- LGR
|
||||
- bnjbvr
|
||||
|
||||
### Notes
|
||||
|
||||
- nothing on the agenda, so random topics were brought up
|
||||
- acrichton expressing appreciation of a really bad bug found by fuzzers,
|
||||
thanks cfallin for setting that up!
|
||||
- abrown asking if new ittapi-rs worked out well in Embark's embedding
|
||||
- bnjbvr: yes! passes cargo deny now
|
||||
- bnjbvr: wasmtime with vtune throws a runtime error on windows, any idea
|
||||
why?
|
||||
- abrown: will check with johnnie
|
||||
- bnjbvr: we've tried enabling wasm SIMD in our embedding! Everything seemed to work fine, except for a small bug. Probably
|
||||
related to a lib using wasm SIMD intrinsics, investigating.
|
||||
- fitzgen: what's up with rustix not compiling on nightly?
|
||||
- old compile bug in rustix that's been fixed there, not updated upstream
|
||||
- fitzgen may follow up with patch bumping the version in wasmtime
|
||||
@@ -1,22 +0,0 @@
|
||||
# January 20th Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. cfallin: memfd and CoW; instance initialization and pooling; epoch
|
||||
interruption
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,64 +0,0 @@
|
||||
# February 3rd Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
### Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. cfallin: update on memfd, CoW, lazy init
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
### Attendees
|
||||
- abrown
|
||||
- acrichton
|
||||
- fitzgen
|
||||
- cfallin
|
||||
- lgr
|
||||
- jlbirch
|
||||
- harold
|
||||
- sunfish
|
||||
|
||||
### Notes
|
||||
|
||||
cfallin: several instantiation performance PRs in the pipeline (or merged):
|
||||
- memfd: anonymous memory file for the heap contents is `mmap`-ed in; can quickly clear any changes in the overlay to reuse it
|
||||
- pooling allocator slot allocation: use the same slot for the module if possible
|
||||
- other changes to instantiation performance: making more things lazy (e.g., `funcref` tables)
|
||||
|
||||
cfallin: with the `funcref` tables change, Wasmtime can instantiate the Spidermonkey Wasn module ~3x faster (72us to 22us)
|
||||
|
||||
acrichton: could be even faster
|
||||
|
||||
jlbirch: in wnat scenarios will we see these benefits?
|
||||
|
||||
cfallin: with the memfd changes there are benefits:
|
||||
- when instantiating just once there is no need to do eager init of memory contents (just `mmap`)
|
||||
- caveat: first instantiation might be net same as current implementation...
|
||||
- additional wins if you can reuse the module's slot
|
||||
- table init chnage is a benefit universally
|
||||
|
||||
jlbirch: when benchmarking, if we observer inconsistent instantiation times, how can we tell if the fast or slow path is taken?
|
||||
|
||||
cfallin: we could expose stats in the affinity allocator
|
||||
|
||||
acrichton: note that the module must be the right shape for affinity to work well--dynamic init messes things up (?); this could be improved to recognize more module shapes
|
||||
|
||||
abrown: what are some best-case numbers for instantiation?
|
||||
|
||||
cfallin: instantiation should be nothing more than an `madvise` call and a few pointer stores
|
||||
|
||||
acrichton: for a multi-MB Wasm file, not even pooling, instantiation can be 10us; caveat: single-threadeded result, may find more issues with concurrency
|
||||
|
||||
lgr: so this pushes towards doing everything on the fly?
|
||||
|
||||
cfallin: yes, majority of work should happen in a new instance--security benefits...
|
||||
|
||||
abrown: ittapi crate (for VTune support) has been improved by me, bnjbvr and jlbirch; almost ready for inclusion in the default Wasmtime build--should we support more OS than Linux, macOS, Windows?
|
||||
|
||||
acrichton: those are the currently supported OS; that should be fine
|
||||
@@ -1,101 +0,0 @@
|
||||
# February 17th Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. Conrad Watt: verified Wasm interpreter as fuzzing oracle
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
- Conrad Watt
|
||||
- cfallin
|
||||
- acrichton
|
||||
- abrown
|
||||
- till
|
||||
- Dan
|
||||
- fitzgen
|
||||
- LGR
|
||||
- Anton Kirilov
|
||||
- Kevin Hoffman
|
||||
- jlbirch
|
||||
|
||||
### Notes
|
||||
|
||||
- Spec interpreter and fuzzing (Conrad Watt)
|
||||
- (slides)
|
||||
- Conrad: reference interpreter; Wasmtime fuzzes with it; but quadratic
|
||||
behavior
|
||||
- Conrad: WasmCert-Isabelle (formally verified Wasm semantics) can extract an
|
||||
interpreter; fixes quadratic behavior. Should we use this?
|
||||
- fitzgen: does interpreter have a concept of execution fuel?
|
||||
- Conrad: yes
|
||||
- fitzgen: great; we can get rid of our wasm-smith fuel instrumentation
|
||||
- Conrad: perf should be roughly equivalent to cfallin's fork of ref
|
||||
interpreter with quadratic behavior fixed
|
||||
- Conrad can open a PR
|
||||
- Conrad: hazards: "teething pains" -- bugs once interpreter is exposed to fuzzing
|
||||
- fitzgen: just fuzz locally a bit before turning on in ossfuzz
|
||||
- Conrad: hazards: no line numbers
|
||||
- cfallin: doesn't matter too much, we just verify that trap or no trap is
|
||||
same on both sides
|
||||
- abrown: add a toplevel CLI tool to run ref interpreter?
|
||||
- Conrad: post-MVP story.
|
||||
- SIMD: can defer to original ref interpreter
|
||||
- cfallin: back to quadratic behavior then, or avoid?
|
||||
- Conrad: no, just uses arithmetic library/semantics part
|
||||
- cfallin: host interaction? GC, imports, etc
|
||||
- Conrad: can call imports all the same; GC is mostly internal to interpreter
|
||||
- fitzgen: multi-module?
|
||||
- Conrad: should be handled
|
||||
- Till: plans about component model?
|
||||
- Conrad: two parts, standardized imports / WASI-like things, and semantics
|
||||
of interface types
|
||||
- Conrad: rely on polyfills for now
|
||||
- fitzgen: module linking moved into component model, supporting that is
|
||||
valuable
|
||||
- Conrad: doable, needs Isabelle model of component model
|
||||
- cfallin: can we fall back to unverified official reference interpreter at
|
||||
the top level (for things like module linking, component model) in addition
|
||||
to SIMD?
|
||||
- Conrad: technically possible
|
||||
- not clear whether this will be implemented in ref interpreter in same way
|
||||
as "lower level" things like SIMD
|
||||
- harder to do "middle-end" things like exception handling without
|
||||
deferring all control flow back to unverified interpreter
|
||||
- fitzgen: stack switching?
|
||||
- Conrad: unclear current state; unaware of concrete proposal close to
|
||||
being brought forward
|
||||
- cfallin: future plans?
|
||||
- Conrad: looking into reference types, bulk memory
|
||||
- Conrad: within 6 mos-1 yr hope to support all currently standardized features
|
||||
- Conrad: want to keep patce with standards track in general
|
||||
- dgohman: checked against formal model in original Wasm paper?
|
||||
- Conrad: "eyeball correspondence": formal model lines up with original
|
||||
paper spec; then interpreter is mechanically verified against this formal
|
||||
model
|
||||
|
||||
- Till: CVE published yesterday in pooling allocator
|
||||
- made us discuss more about ensuring we're fuzzing all configurations.
|
||||
Previously had rule about fuzzing all implemented Wasm specs for two weeks;
|
||||
now extended to all configs as well
|
||||
- fitzgen wrote a GitHub bot to post a checklist on config changes ensuring this
|
||||
|
||||
- cfallin: updates on memfd, lazy table, epochs
|
||||
- instantiation got faster! SpiderMonkey.wasm instantiation from ~a few ms
|
||||
down to 3µs
|
||||
- not on by default in 0.34; should be in 0.35 (letting it bake in fuzzing
|
||||
for one more week)
|
||||
- epochs: faster way to do cooperative timeslicing than fuel; 1.5-2x better;
|
||||
only downside is nondeterministism
|
||||
|
||||
- Liam: KubeCon, call for talks
|
||||
@@ -1,20 +0,0 @@
|
||||
# March 3rd Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,24 +0,0 @@
|
||||
# March 17th Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. Release policy discussion
|
||||
- Policy around "when should we do a point release" is underspecified;
|
||||
clarify and establish guidelines one way or another
|
||||
1. Development plan for the component model
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,22 +0,0 @@
|
||||
# March 31st Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. Wasmtime release fuzzing strategy
|
||||
- see [#3955](https://github.com/bytecodealliance/wasmtime/pull/3955) for more context
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# April 14th Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,57 +0,0 @@
|
||||
# April 28th Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
- sunfishcode
|
||||
- fitzgen
|
||||
- LGR
|
||||
- abrown
|
||||
- jlbirch
|
||||
- gkulakowski
|
||||
- akirilov
|
||||
- acrichton
|
||||
- cfallin
|
||||
- npmccallum
|
||||
|
||||
### Notes
|
||||
|
||||
- wasi-common polling interface
|
||||
- Nathaniel: can we add a custom poller interface, maybe based on traits,
|
||||
to wasi-common? Need this to virtualize a TLS socket fd in Enarx: polling
|
||||
on underlying fd may cause spurious wakeups otherwise (bytes for TLS
|
||||
layer do not necessarily become ready bytes for user).
|
||||
- Dan: yes, interested in this general discussion/idea. One thing to note
|
||||
is wasi-common will be rewritten soon in terms of wit-bindgen and
|
||||
streams, etc (more writeup/details to come). Short-term fix: use a Unix
|
||||
pipe or socket pair?
|
||||
- Nathaniel: actually we can't do that in our situation, trust boundary
|
||||
issue: kernel not allowed to see plaintext, it stays within confidential
|
||||
sandbox.
|
||||
- Dan: Cargo feature to add custom code? Also, maybe we can do a dedicated
|
||||
meeting to brainstorm.
|
||||
- Nathaniel: sure, happy to meet. Basic high-level idea to keep in mind is
|
||||
not to assume that hostcalls at WASI layer go to kernel; current impl is
|
||||
written in a way that assumes it is a thin wrapper around kernel.
|
||||
- Dan: streams in wit-bindgen
|
||||
- Nathaniel: (more ideas about trait design, missed some details)
|
||||
- Dan: interesting question in general: how do we do a general poll that
|
||||
polls over real IO and also synthesized/virtualized IO all at once?
|
||||
- Nathaniel: trait approach would allow per-platform default impl, and
|
||||
maybe people would wrap this with their own custom stuff
|
||||
- George: to Dan: is async/wit-bindgen refactor written up?
|
||||
- Dan: working on it now! Will post it soon.
|
||||
Binary file not shown.
@@ -1,85 +0,0 @@
|
||||
# May 12th Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. Discuss extending the pollers API
|
||||
1. Discuss shared memory implementation (i.e., changes to `VMContext`)
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
- acrichton
|
||||
- cfallin
|
||||
- fitzgen
|
||||
- bnjbvr
|
||||
- saulcabrera
|
||||
- gkulakowksi
|
||||
- dgohman
|
||||
- abrown
|
||||
- jlbirch
|
||||
- LGR
|
||||
|
||||
### Notes
|
||||
|
||||
1. extending the pollers API
|
||||
- Dan: Profian has interesting constraints: encryption inside an enclave.
|
||||
Polling on encrypted bytes ready is not the same as plaintext ready.
|
||||
- Dan: poll() should work for OS-level things and synthesized things as
|
||||
well.
|
||||
- Dan: timerfd is one possibility
|
||||
- Dan: request from Profian is maybe a trait at wasmtime level
|
||||
- Dan: maybe WASI virtualization is a better answer
|
||||
- Alex: could they override just one function in WASI interface (poll)?
|
||||
- George: sounds like that's what they're doing now, too much work, too
|
||||
intrusive, hard to maintain
|
||||
- Dan: or maybe Cargo feature in Wasmtime with totally custom thing for
|
||||
enclaves?
|
||||
- Alex: basically what I'm saying, but poll function overridden at Linker,
|
||||
no need for special stuff in Wasmtime internals
|
||||
- Dan: second half of discussion: poll to be replaced by wait function in
|
||||
WASI on canonical ABI / new async stuff
|
||||
- Alex: final state is everything is async at embedder API level; not sure
|
||||
about transition path
|
||||
- Dan: sounds right, TLS thing can be done in Rust async eventually.
|
||||
Question is transitional plan
|
||||
- Dan: maybe this means we have a bit higher tolerance for now for temporary
|
||||
workarounds
|
||||
- Andrew: what does the async timeline look like?
|
||||
- Alex: working on it, lots of spec work, still a bit unsure
|
||||
- Dan: recently started working on a "preview 2" snapshot of WASI, based on
|
||||
some new async stuff; timeline is months
|
||||
|
||||
2. Shared memory implementation (i.e., changes to `VMContext`)
|
||||
- Andrew: [slides](wasmtime-05-12-slides.pdf)
|
||||
- Andrew: working on shared memory in Wasmtime, help from Alex.
|
||||
- Andrew: main problem is how to share `current_length` in
|
||||
`VMMemoryDefinition`, which has a separate copy in each instance
|
||||
- Dan: could we "notify", push new lengths to all copies?
|
||||
- Chris: we could also lazily update: on trap, look at central
|
||||
atomically-updated length and pull in new one if spurious trap. Or:
|
||||
generate a slowpath that fetches the atomic and updates, for dynamic
|
||||
bounds checks?
|
||||
- Alex: would be concerned about code size
|
||||
- Chris: make `current_length` a `*const AtomicUsize`, always fetch?
|
||||
- Nick: concerned about double-indirection cost
|
||||
- Alex: we have double-indirection today for some (imported) memories
|
||||
- Nick: benchmarks would be interesting
|
||||
- (lots of discussion about tradeoffs, fell behind on notes)
|
||||
- Nick: interesting case where mprotect happens before length field
|
||||
increments, other threads observe working accesses but read smaller
|
||||
memory.size; need lock to protect size too (need memory.size hostcall for
|
||||
correctness)
|
||||
- Takeaways: Andrew will look at perf overhead, and also figure out why V8
|
||||
is not doing paging tricks for shared memories (are we missing something)
|
||||
- Ben: we should look at what SpiderMonkey does too
|
||||
@@ -1,20 +0,0 @@
|
||||
# May 26th Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# June 9th Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# June 23rd Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# July 7th Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# July 21st Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# August 4th Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# August 18th Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# September 1st Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# September 15th Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# September 29th Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# October 13th Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# October 27th Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# November 10th Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,20 +0,0 @@
|
||||
# December 8th Wasmtime project call
|
||||
|
||||
**See the [instructions](../README.md) for details on how to attend**
|
||||
|
||||
## Agenda
|
||||
1. Opening, welcome and roll call
|
||||
1. Note: meeting notes linked in the invite.
|
||||
1. Please help add your name to the meeting notes.
|
||||
1. Please help take notes.
|
||||
1. Thanks!
|
||||
1. Announcements
|
||||
1. _Submit a PR to add your announcement here_
|
||||
1. Other agenda items
|
||||
1. _Submit a PR to add your item here_
|
||||
|
||||
## Notes
|
||||
|
||||
### Attendees
|
||||
|
||||
### Notes
|
||||
@@ -1,21 +0,0 @@
|
||||
# Wasmtime project meetings
|
||||
|
||||
The Wasmtime project holds bi-weekly meetings, and we welcome all interested parties to join.
|
||||
|
||||
## Time and location
|
||||
|
||||
**When**: every second Thursday at 4pm UTC during US DST / 5pm UTC otherwise
|
||||
**Where**: Zoom (link in calendar invite)
|
||||
|
||||
|
||||
## Attending
|
||||
|
||||
To attend, please email <till@bytecodealliance.org>, or reach out [on Zulip](https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime).
|
||||
|
||||
## Agendas and notes
|
||||
|
||||
Both agendas for upcoming and notes for past meetings will be posted in subdirectories for each year.
|
||||
|
||||
## Adding agenda items
|
||||
|
||||
To add something to the agenda for an upcoming meeting, open a pull request to modify the agenda.
|
||||
Reference in New Issue
Block a user