Add cranelift meeting notes (#3411)

* Add cranelift meeting tnoes

* Update cranelift-10-04.md

meetings/cranelift/2021/cranelift-10-04.md

@@ -14,8 +14,155 @@
     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)) 
 
-## Notes
-
 ### 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!