Stream: rfc-notifications

Topic: rfcs / issue #15 RFC: design of ISLE instruction-selector...

view this post on Zulip RFC notifications bot (Aug 19 2021 at 05:49):

cfallin commented on issue #15:

cc folks who participated in #13 and/or may be interested due to involvement in Cranelift backends: @fitzgen @sunfishcode @tschneidereit @abrown @jlb6740 @akirilov-arm @afonso360 @bjorn3

view this post on Zulip RFC notifications bot (Aug 19 2021 at 13:27):

bjorn3 commented on issue #15:

One question I have before reading this RFC, would it be possible to have backend agnostic rules for things like 128bit ints or 64bit ints on 32bit systems? Kind of like the old legalization system, except without having to edit the clif ir in-place. As different architectures work differently, it may make sense to have partially or fully different rule sets for architectures with and without flags. In addition it should be possible to override rules for specific backends if they can do it more efficiently.

view this post on Zulip RFC notifications bot (Aug 19 2021 at 19:56):

cfallin commented on issue #15:

Sorry if I've missed it, but my main confusion is over how extractor functions are defined, is the nitty gritty matching done in Rust and will just reuse the existing code?

Extractors are defined in Rust, yeah, so it's sort of an FFI to "runtime library code" (from the point of view of the DSL). But they should be low-level: I expect that we'll have extractors for the LowerCtx API, e.g. fetching instructions that feed into operands, fetching immediates, and that sort of thing, plus machine-specific things like the various immediate formats (imm12, immlogic), plus maybe other escape hatches to general logic where we really need it.

Also, would we be able to express instructions that have multiple outputs, such as pre/post indexed memory operations?

This is an interesting one! In the most general form it needs multi-rooted DAG matching (i.e. we need to find the load/store and the add-to-pointer separately), which needs adjustments to our lowering loop as well. I don't see why a term-rewriting system in general couldn't express that, but it needs further thought.

view this post on Zulip RFC notifications bot (Aug 19 2021 at 19:57):

cfallin commented on issue #15:

One question I have before reading this RFC, would it be possible to have backend agnostic rules for things like 128bit ints or 64bit ints on 32bit systems? Kind of like the old legalization system, except without having to edit the clif ir in-place. As different architectures work differently, it may make sense to have partially or fully different rule sets for architectures with and without flags. In addition it should be possible to override rules for specific backends if they can do it more efficiently.

Indeed! The hope is that we can get back to that universe where we have fallback rules. In particular this should make e.g. fuller i128 support across all platforms, and also the eventual buildout of our 32-bit platform support (if someone is sufficiently motivated to drive it), much easier.

view this post on Zulip RFC notifications bot (Aug 20 2021 at 18:10):

cfallin commented on issue #15:

I'm slightly concerned about compile times. Working on LLVM and editing a .td file in one of the targets is not a great experience. It usually involves at least a 1 min build for my laptop, which is really disruptive. And while I now have a much better experience with a different machine, I would hate for us to find ourselves in the same situation.

I don't know if this is going to be an issue, but we may want to think about ways to mitigate it if it does.

I agree this could be a problem -- we'll have to see what it looks like when we have a prototype ready (it's coming soon-ish!).

There are really three aspects to this, and we could make a difference to one of them with a certain change:

At least the first two (building the metacompiler, and invoking the metacompiler to generate Rust code from the DSL) could be removed from the Cranelift build time when the DSL code is unchanged by checking the generated Rust code into source control. I'll note that this is not the idiomatic Rust approach at all (that would be to run this from build.rs and put the output in target/); but it's an option, and does have some other attractive properties, e.g. making the generated code much easier to find for anyone who needs to follow or debug it. On the other hand, it adds potential for surprising errors when it gets out-of-sync.

The edit-run debug loop depends on the last two only (presumably the DSL metacompiler will be built once then won't be changed if one is hacking on a backend); we get all three only when hacking on the metacompiler itself.

Anyway, whether or not to check in the generated artifacts is a question we can discuss here as well -- thoughts?

view this post on Zulip RFC notifications bot (Aug 20 2021 at 18:10):

cfallin edited a comment on issue #15:

I'm slightly concerned about compile times. Working on LLVM and editing a .td file in one of the targets is not a great experience. It usually involves at least a 1 min build for my laptop, which is really disruptive. And while I now have a much better experience with a different machine, I would hate for us to find ourselves in the same situation.

I don't know if this is going to be an issue, but we may want to think about ways to mitigate it if it does.

I agree this could be a problem -- we'll have to see what it looks like when we have a prototype ready (it's coming soon-ish!).

There are really three aspects to this, and we could make a difference to the first two with a certain change:

At least the first two (building the metacompiler, and invoking the metacompiler to generate Rust code from the DSL) could be removed from the Cranelift build time when the DSL code is unchanged by checking the generated Rust code into source control. I'll note that this is not the idiomatic Rust approach at all (that would be to run this from build.rs and put the output in target/); but it's an option, and does have some other attractive properties, e.g. making the generated code much easier to find for anyone who needs to follow or debug it. On the other hand, it adds potential for surprising errors when it gets out-of-sync.

The edit-run debug loop depends on the last two only (presumably the DSL metacompiler will be built once then won't be changed if one is hacking on a backend); we get all three only when hacking on the metacompiler itself.

Anyway, whether or not to check in the generated artifacts is a question we can discuss here as well -- thoughts?

view this post on Zulip RFC notifications bot (Sep 10 2021 at 01:30):

cfallin commented on issue #15:

Greetings all! I've been churning on a little prototype of the DSL described in this RFC -- or at least something very close to it, with tweaks as needed as I discovered interesting issues in implementation -- in order to get a feel for its semantics.

For your consideration, a small sketch of an instruction selector in this commit. It doesn't actually do anything yet; it's not wired up to the rest of Cranelift; but it does successfully pass through this prototype ISLE compiler and generate some Rust code.

The little sketch in the commit above has some "prelude" that gives definitions to glue the DSL onto Cranelift, but the interesting bit is in x64/lower.isle -- some sample rules:

(rule
 (Lower (Iadd a (InputConst k)))
 (X86Add (InputToReg a)
         (RegMemImm.Imm k)))
(rule
 (Lower (Iadd (InputConst k) b))
 (X86Add (InputToReg b)
         (RegMemImm.Imm k)))
(rule
 (Lower (Iadd a b))
 (X86Add (InputToReg a)
         (RegMemImm.Reg (InputToReg b))))

(rule
 (Lower (Iadd a (InputSourceInst (Load addr off))))
 (X86Add
  (InputToReg a)
  (RegMemImm.Mem (Mem.BaseImm (InputToReg addr) off))))
(rule
 (Lower (Iadd (InputSourceInst (Load addr off)) a))
 (X86Add
  (InputToReg a)
  (RegMemImm.Mem (Mem.BaseImm (InputToReg addr) off))))

This all can be bikeshedded to fine-tune the actual types and definitions as much as we want; the point is that we have a term-rewriting system, and descriptive terms in the "extractors" (LHS terms) and "constructors" (RHS terms).

To head off any quick reactions to the verbose terms like InputSourceInst and questions such as "why not just (Iadd (Load ...) ...)? I'd point back to the section of the RFC that motivates the "programmable extractors" with examples where we might want more than one such "virtual term" to be possible in a given context.

To the best of my thinking right now, all of these rules are compatible with our main goals -- both quick (single-pass) lowering as compiled by the prototype compiler above, and a value-equivalence-based view of the lowering to aid verification and other formal efforts. (To see how, think of e.g. InputSourceInst as just the identity function -- it's a type-adapter that makes the lowering work but doesn't change the "value".)

Let me know what you think! I am going to context-switch away from this for a little bit but (i) I will plan to braindump a good amount about the internals / implementation details / what I've learned while prototyping the compiler-compiler, and (ii) I do intend the above prototype to be a "real" starting point (modulo some cleanups) that we can develop into the actual implementation, if this RFC is accepted.

view this post on Zulip RFC notifications bot (Sep 13 2021 at 22:06):

fitzgen commented on issue #15:

(rule (Lower (Iadd a (InputSourceInst (Load addr off)))) (X86Add (InputToReg a) (RegMemImm.Mem (Mem.BaseImm (InputToReg addr) off)))) (rule (Lower (Iadd (InputSourceInst (Load addr off)) a)) (X86Add (InputToReg a) (RegMemImm.Mem (Mem.BaseImm (InputToReg addr) off))))

Is the idea that the InputSourceInst extractor will fail if the load isn't the same color as this operation and so we don't need to expose the coloring to the DSL, or is the lack of coloring here an oversight/simplification?

Either way, I think that either building the coloring logic into the InputSourceInst extractor or exposing a new extractor specifically for checking color could work here.

view this post on Zulip RFC notifications bot (Sep 13 2021 at 22:18):

cfallin commented on issue #15:

Is the idea that the InputSourceInst extractor will fail if the load isn't the same color as this operation and so we don't need to expose the coloring to the DSL

Yes, exactly, it's a wrapper (or will be once we write the trait impl) around the LowerCtx method to get the producer for an input, which implements the logic (involving matching color and/or purity) that allows an instruction to be merged in. So it will always fail when we aren't able to merge that far up the tree; all we need to reason about in the DSL is the shape of the tree that we want to match.

view this post on Zulip RFC notifications bot (Sep 13 2021 at 22:19):

cfallin edited a comment on issue #15:

Is the idea that the InputSourceInst extractor will fail if the load isn't the same color as this operation and so we don't need to expose the coloring to the DSL

Yes, exactly, it's a wrapper (or will be once we write the trait impl) around the LowerCtx::get_input_as_source_or_const method to get the producer for an input, which implements the logic (involving matching color and/or purity) that allows an instruction to be merged in. So it will always fail when we aren't able to merge that far up the tree; all we need to reason about in the DSL is the shape of the tree that we want to match.

view this post on Zulip RFC notifications bot (Sep 17 2021 at 07:57):

bnjbvr commented on issue #15:

While I think a better way to handle instruction selection and generation is necessary, I have a few concerns about this proposal, especially around this not reaching the ideal goal of simplicity we're looking for, and I am unsure about the use of a custom DSL for this task.

Moving the debate out of the comment, I think this doesn't get us to a better place in terms of simplicity. Simplicity/easiness-to-use is largely subjective anyways, and the creator bias/hindsight bias make it so that a system one creates likely appears as being _simple_ to their own eyes. However, here even after re-reading the proposals a few times, I'm still hesitant about a few concepts that seem to be key to knowing how to do things (extractor/entrypoints/...). Introducing concepts is inevitable of course, but if these are hard to grasp for a majority of current and future contributors, the system wouldn't be very welcoming for users, becoming a large barrier to entry. I grasp from other people asking for detailed examples and supplementary blog posts explaining this new ISLE framework that I might not be the only one having uncertainties here; don't want to read too much into this, because I think I have been the only one expressing explicit concerns of this kind so far. In terms of complexity, I see it like this: adding a new single instruction? Probably fine, I can just copy-paste some other ISLE code, stealing bits here and there. Add a way to find a new kind of patterns? Unclear if I could do it. So adding a whole new target ISA? Sounds scary. All these things feel straightforward to me in the existing code base, but I am myself subject to the creator bias, of course :-) and navigating the code base is pretty easy thanks to the great Rust developer tools.

And that relates to the second point: using a custom DSL for this kind of work would be a clear step backwards, in my opinion. We're talking about a small programming language here, which implementation will be tweaked, which "programs" (ISLE definitions) will need to be debugged, optimized, etc. Moving the old meta framework from Python to Rust was a clear win, because we got static typing which removed a whole range of error-proneness, and a better developer environment in general: being able to share code between codegen and meta, using Rust packages in the meta crate if needs be, using all the developer tools included in IDE (rust-analyzer :heart:️). So getting back to a custom DSL, we'd lose debuggers, IDE functionalities, namely jump-to-definition i.e. the ability to look how things are implemented ("what's an extractor? oh I could just jump to its definition, owait no, it's done in a different language at a different level, might as well just grep around in the code base, hoping that i'll find where/how it's done"). This is not intractable of course, and all these tools _could_ be reimplemented but that might be a waste of resources to do so. Any of Rust/Python/TypeScript would be better fits at this point, since they now all have good development ecosystems (with a clear preference for Rust, of course!).

Please bear with me, here: I am fully _in favor of_ a change in the way we're doing instruction selection, understanding all the benefits, but I am not convinced the proposal in its current state would solve our complexity issues.

view this post on Zulip RFC notifications bot (Sep 17 2021 at 08:48):

cfallin commented on issue #15:

@bnjbvr thank you for taking the time to detail your concerns here!

First, at a high level: I'm glad that we agree that some sort of DSL or systematized approach is necessary. The recent string of SIMD-related fuzzbugs, and other difficulties we've had in the past in communicating some of the subtle requirements and invariants in the current handwritten backends (e.g., regalloc metadata, when it is safe to use registers, when it is safe to sink an instruction, and some of the subtle bugs that have resulted when we get this wrong), have convinced me pretty solidly that we need to automate; a handwritten approach, while tempting below a certain level of intrinsic complexity (number of lowering cases / instructions), is just too error-prone.

There are also the things that we just can't do today, that a systematized DSL would enable: large-scale refactors that alter how the lowering works (e.g., switching to a new regalloc API, or a different emission strategy), combining multiple layers of rewrite rules or manipulating/processing them in some other way (e.g. Peepmatic-style generated simplification patterns), and consuming the lowering patterns for other uses, such as verification. So, in my mind, we need a DSL; the question is just whether this one is the right one.

If I'm reading your main concerns right, I think they distill down to this -- please correct me if I mis-state anything:

Both of these are real issues and I think that weighing these against the benefits is largely a subjective question. But I want to dive in a bit on each.

Complexity of mental model: it might be useful to start from a pure term-rewriting system as a neutral, fairly mainstream sort of approach (see e.g. the Go compiler's DSL, or tablegen's expression trees). In your view, is this sort of approach reasonably approachable, or does it suffer from some of the same issues? In other words, I'm trying to distill whether some of the new concepts in ISLE specifically (extractors, single-pass lowering) are the issue, or instead if the issue is just thinking in terms of layered rewrite rules.

If the former, I think we can definitely try to refine the terminology, or give better examples. If the idea of a programmable extractor in particular is ultimately too weird or objectionable, I can imagine some alternative ways of getting the same thing -- maybe we have constructors on the right-hand side instead that can fail to match. If the latter, and all term-rewriting systems raise concerns, then I think we're at more of a philosophical impasse, since that way of representing instruction lowering is so powerful for all the other things we want to do, but I'm still happy to discuss more :-)

Discoverability: this one is a bit harder, and I agree that pure Rust code is the gold standard w.r.t. discoverable definitions and autocompletions. I do want to note re: your listed advantages above that ISLE, too, is strongly statically typed, unlike a lot of other past term-rewriting systems; so it will at least catch type errors, if not proactively help avoid them in an IDE.

I'm curious, though, if you have better ideas to address it -- an EDSL in Rust somehow? If so, I'm not sure how we'd be able to do the transforms we want to do -- if you squint enough, the ISLE compiler is sort of doing a "transpose", in that it's weaving together a bunch of different lowering-pattern rules by their common prefixes. It's thus a kind of global transform, and would probably need a Rust compiler plugin, rather than just e.g. Rust macros that build data structures, as the cranelift-codegen-meta DSL does. I'm very open to suggestions here.

Anyway, that's my braindump for now; hopefully we can come to a better consensus here, or at least distill out the subjective decision points that underlie the space!

view this post on Zulip RFC notifications bot (Sep 17 2021 at 17:08):

fitzgen commented on issue #15:

Hi @bnjbvr :)

First off, I want to recognize that your concerns are valid, particularly around IDEs and developer tooling. I think that is just a fundamental trade off of using a DSL vs open coding, and something we need to explicitly acknowledge and accept if we are going to go down the DSL route.

Aside: Although embedded (within the "main" language) DSLs (EDSLs, as @cfallin mentioned (apologies if you are already familiar with this terminology)) can sometimes have their cake and eat it too with regards to tooling vs DSL. In Rust I think that would probably look like some kind of macro sugar language because I don't think Rust's regular abstraction capabilities would allow us to express the kinds of transformations and combinations of rules that we want to express. However, (a) my experience has been that rust-analyzer isn't great at seeing through macros, and (b) if we use procedural macros (rather than macro-rules macros, which again probably can't do the kinds of transforms/combos we want) then we arguably aren't really doing an EDSL anymore since we are just compiling arbitrary code to Rust in arbitrary ways. So I don't think we can have our cake and eat it too in this particular case.

All that said, as someone who hasn't contributed to the new backends, I personally find ISLE more inviting than the open-coded backends. Many grains of salt here, since I did some research into Go's/GCC's/etc DSLs for instruction selection and peephole optimizations when designing and implementing Peepmatic, so I've already made myself familiar with this term-rewriting paradigm.

It was also helpful to step through a few very small examples with @cfallin the other day. We started with just the rule to lower an arbitrary iadd, putting both operands in registers. Then we inspected the generated Rust code. Next, we added rules for if the first operand is an iconst that fits in an immediate and lowered that into an add-with-immediate, and did the same for the second operand. Then we inspected the generated Rust code for these three, partially overlapping rules. This gave me a lot of confidence in the ISLE compiler, and that it is basically doing what I expect it should. I would recommend this exercise to others as well, and I'm happy to pair with people to go through it, if anyone would like.

view this post on Zulip RFC notifications bot (Sep 17 2021 at 19:34):

cfallin commented on issue #15:

As a heads-up, I just added a Cranelift biweekly meeting agenda item to discuss this more -- @bnjbvr, @fitzgen and any others, perhaps we can talk more through these concerns and thoughts then!

view this post on Zulip RFC notifications bot (Sep 17 2021 at 19:35):

cfallin edited a comment on issue #15:

As a heads-up, I just added a Cranelift biweekly meeting agenda item (edit: for this coming Monday's meeting) to discuss this more -- @bnjbvr, @fitzgen and any others, perhaps we can talk more through these concerns and thoughts then!

view this post on Zulip RFC notifications bot (Sep 20 2021 at 14:50):

bnjbvr commented on issue #15:

Thanks. As a note, I won't be able to attend this particular meeting because of a conflict.

view this post on Zulip RFC notifications bot (Sep 24 2021 at 16:24):

cfallin commented on issue #15:

Just coordinated briefly with @bnjbvr and have now added an agenda item for the next (Mon Oct 4) Cranelift meeting -- anyone interested in continuing the discussion please feel free to join!

view this post on Zulip RFC notifications bot (Oct 04 2021 at 21:14):

fitzgen commented on issue #15:

FYI, I have added a tutorial and implementation overview to ISLE's README.md.

view this post on Zulip RFC notifications bot (Nov 01 2021 at 16:29):

cfallin commented on issue #15:

Hi all -- thanks for the continuing input and patience on this long-running effort!

@fitzgen gave an excellent update on his progress driving forward the prototype Cranelift integration for ISLE, and example implementations of several instruction lowerings. The general consensus from the meeting was that there are no strong objections to moving forward with this. So, with that in mind, I would like to make a...

Motion to finalize with a disposition to merge

Stakeholders sign-off

Arm

DFINITY

Embark Studios

Fastly

Google/Envoy

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (Nov 01 2021 at 16:30):

cfallin edited a comment on issue #15:

Hi all -- thanks for the continuing input and patience on this long-running effort!

@fitzgen gave an excellent update on his progress driving forward the prototype Cranelift integration for ISLE in the Cranelift biweekly today, and example implementations of several instruction lowerings. The general consensus from the meeting was that there are no strong objections to moving forward with this. So, with that in mind, I would like to make a...

Motion to finalize with a disposition to merge

Stakeholders sign-off

Arm

DFINITY

Embark Studios

Fastly

Google/Envoy

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (Nov 01 2021 at 16:31):

fitzgen edited a comment on issue #15:

Hi all -- thanks for the continuing input and patience on this long-running effort!

@fitzgen gave an excellent update on his progress driving forward the prototype Cranelift integration for ISLE in the Cranelift biweekly today, and example implementations of several instruction lowerings. The general consensus from the meeting was that there are no strong objections to moving forward with this. So, with that in mind, I would like to make a...

Motion to finalize with a disposition to merge

Stakeholders sign-off

Arm

DFINITY

Embark Studios

Fastly

Google/Envoy

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (Nov 01 2021 at 16:31):

fitzgen commented on issue #15:

Fwiw, here are the slides for the update I gave at today's cranelift meeting: https://docs.google.com/presentation/d/1b6psjaIKkVTZGaGzMcw9h_Ahgih-ctUcnz0Dbjn11GI/edit

view this post on Zulip RFC notifications bot (Nov 01 2021 at 16:42):

cfallin edited a comment on issue #15:

Hi all -- thanks for the continuing input and patience on this long-running effort!

@fitzgen gave an excellent update on his progress driving forward the prototype Cranelift integration for ISLE in the Cranelift biweekly today, and example implementations of several instruction lowerings. The general consensus from the meeting was that there are no strong objections to moving forward with this. So, with that in mind, I would like to make a...

Motion to finalize with a disposition to merge

Stakeholders sign-off

Arm

DFINITY

Embark Studios

Fastly

Google/Envoy

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (Nov 01 2021 at 16:43):

cfallin commented on issue #15:

(sorry @alexcrichton, just noticed your name was missing -- I had copied the checkbox list from your latest RFC's motion-to-finalize comment. added now!)

view this post on Zulip RFC notifications bot (Nov 01 2021 at 17:09):

pchickey edited a comment on issue #15:

Hi all -- thanks for the continuing input and patience on this long-running effort!

@fitzgen gave an excellent update on his progress driving forward the prototype Cranelift integration for ISLE in the Cranelift biweekly today, and example implementations of several instruction lowerings. The general consensus from the meeting was that there are no strong objections to moving forward with this. So, with that in mind, I would like to make a...

Motion to finalize with a disposition to merge

Stakeholders sign-off

Arm

DFINITY

Embark Studios

Fastly

Google/Envoy

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (Nov 01 2021 at 17:28):

cfallin edited a comment on issue #15:

Hi all -- thanks for the continuing input and patience on this long-running effort!

@fitzgen gave an excellent update on his progress driving forward the prototype Cranelift integration for ISLE in the Cranelift biweekly today, and example implementations of several instruction lowerings. The general consensus from the meeting was that there are no strong objections to moving forward with this. So, with that in mind, I would like to make a...

Motion to finalize with a disposition to merge

Stakeholders sign-off

Arm

DFINITY

Embark Studios

Fastly

Google/Envoy

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (Nov 02 2021 at 20:09):

tschneidereit edited a comment on issue #15:

Hi all -- thanks for the continuing input and patience on this long-running effort!

@fitzgen gave an excellent update on his progress driving forward the prototype Cranelift integration for ISLE in the Cranelift biweekly today, and example implementations of several instruction lowerings. The general consensus from the meeting was that there are no strong objections to moving forward with this. So, with that in mind, I would like to make a...

Motion to finalize with a disposition to merge

Stakeholders sign-off

Arm

DFINITY

Embark Studios

Fastly

Google/Envoy

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (Nov 03 2021 at 16:08):

cfallin edited a comment on issue #15:

Hi all -- thanks for the continuing input and patience on this long-running effort!

@fitzgen gave an excellent update on his progress driving forward the prototype Cranelift integration for ISLE in the Cranelift biweekly today, and example implementations of several instruction lowerings. The general consensus from the meeting was that there are no strong objections to moving forward with this. So, with that in mind, I would like to make a...

Motion to finalize with a disposition to merge

Stakeholders sign-off

Arm

DFINITY

Embark Studios

Fastly

Google/Envoy

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (Nov 03 2021 at 17:45):

cfallin commented on issue #15:

Now that we have signoffs from two separate groups, as per

Once any stakeholder from a different group has signed off, the RFC will move into a 10 calendar day final comment period (FCP), long enough to ensure that other stakeholders have at least a full business week to respond.

we are moving into the Final Comment Period. The FCP will end on Monday, November 15.

view this post on Zulip RFC notifications bot (Nov 15 2021 at 12:45):

uweigand commented on issue #15:

This is OK with me.

view this post on Zulip RFC notifications bot (Nov 15 2021 at 16:08):

cfallin edited a comment on issue #15:

Hi all -- thanks for the continuing input and patience on this long-running effort!

@fitzgen gave an excellent update on his progress driving forward the prototype Cranelift integration for ISLE in the Cranelift biweekly today, and example implementations of several instruction lowerings. The general consensus from the meeting was that there are no strong objections to moving forward with this. So, with that in mind, I would like to make a...

Motion to finalize with a disposition to merge

Stakeholders sign-off

Arm

DFINITY

Embark Studios

Fastly

Google/Envoy

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (Nov 15 2021 at 16:10):

cfallin commented on issue #15:

Hi all -- now that the Final Comment Period has elapsed and there are no pending objections, it is time to merge this RFC!

The next step will be review and landing of the initial code itself. I plan to put together some language-reference-like documentation for the DSL itself, and I'm happy to help answer questions and onboard folks in general as we transition the codegen backends to this new approach!

view this post on Zulip RFC notifications bot (Nov 15 2021 at 16:33):

akirilov-arm edited a comment on issue #15:

Hi all -- thanks for the continuing input and patience on this long-running effort!

@fitzgen gave an excellent update on his progress driving forward the prototype Cranelift integration for ISLE in the Cranelift biweekly today, and example implementations of several instruction lowerings. The general consensus from the meeting was that there are no strong objections to moving forward with this. So, with that in mind, I would like to make a...

Motion to finalize with a disposition to merge

Stakeholders sign-off

Arm

DFINITY

Embark Studios

Fastly

Google/Envoy

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

Last updated: Nov 22 2024 at 16:03 UTC