Stream: rfc-notifications

Topic: rfcs / PR #21 Cranelift/ISLE: allow extended left-hand-si...


view this post on Zulip RFC notifications bot (Apr 25 2022 at 04:51):

cfallin opened PR #21 from isle-extended-patterns to main:

Rendered

This RFC proposes an extension to the ISLE pattern-matching DSL used by Cranelift's code generation
backends. The extension is a backward-compatible proposal that is meant to make certain lowering
patterns easier to express. The ideas are informed by our experience so far with the DSL, and aim
to replace some awkward uses of extractors with in-arguments with clearer, more direct idioms
using a new language form.

cc @abrown @fitzgen @jlb6740 @akirilov-arm @sparker-arm @uweigand

view this post on Zulip RFC notifications bot (Apr 25 2022 at 04:56):

cfallin updated PR #21 from isle-extended-patterns to main.

view this post on Zulip RFC notifications bot (Apr 25 2022 at 04:58):

cfallin updated PR #21 from isle-extended-patterns to main.

view this post on Zulip RFC notifications bot (Apr 26 2022 at 14:53):

avanhatt submitted PR review.

view this post on Zulip RFC notifications bot (Apr 26 2022 at 14:53):

avanhatt submitted PR review.

view this post on Zulip RFC notifications bot (Apr 26 2022 at 14:53):

avanhatt created PR review comment:

Can we expand on this a bit? I.e., if any given clause is unable to match, the rule does not match? Also, including the case of a boolean predicate more explicitly here?

view this post on Zulip RFC notifications bot (Apr 26 2022 at 14:53):

avanhatt created PR review comment:

To this end, would it make sense to name this something like if-let instead of given? I ask both for clarity in my own understanding and as an actual naming suggestion :)

view this post on Zulip RFC notifications bot (Apr 26 2022 at 14:53):

avanhatt created PR review comment:

The "with no given clauses" bit here doesn't make sense to me---presumably, the elided RHS here uses variables bound in the given clauses, so what does it mean to behave the same as before?

view this post on Zulip RFC notifications bot (Apr 26 2022 at 14:53):

avanhatt created PR review comment:

Might be helpful here to explicitly call out the difference between RHS expressions and LHS patterns again, since "expression" could be read in a less-specific way.

view this post on Zulip RFC notifications bot (Apr 26 2022 at 16:12):

cfallin submitted PR review.

view this post on Zulip RFC notifications bot (Apr 26 2022 at 16:12):

cfallin created PR review comment:

Ah, I think this is just ambiguous wording. This isn't saying that one can strip clauses from a particular rule and have it behave the same as before; this is saying that rules with no given clauses behave the same as before. (In other words, meanings of rules with no given clauses do not change.)

view this post on Zulip RFC notifications bot (Apr 26 2022 at 17:22):

cfallin submitted PR review.

view this post on Zulip RFC notifications bot (Apr 26 2022 at 17:22):

cfallin created PR review comment:

It's basically the same as an if let in Rust, indeed! I do kind of like this suggestion. @fitzgen @abrown thoughts?

view this post on Zulip RFC notifications bot (Apr 26 2022 at 17:25):

avanhatt submitted PR review.

view this post on Zulip RFC notifications bot (Apr 26 2022 at 17:25):

avanhatt created PR review comment:

Makes sense! The singular the rule was what tripped me, maybe better as (rules without given clauses behave the same as before)

view this post on Zulip RFC notifications bot (Apr 26 2022 at 20:28):

fitzgen created PR review comment:

I like if-let instead of given

view this post on Zulip RFC notifications bot (Apr 26 2022 at 20:28):

fitzgen submitted PR review.

view this post on Zulip RFC notifications bot (Apr 26 2022 at 20:38):

cfallin updated PR #21 from isle-extended-patterns to main.

view this post on Zulip RFC notifications bot (Apr 26 2022 at 20:38):

cfallin submitted PR review.

view this post on Zulip RFC notifications bot (Apr 26 2022 at 20:38):

cfallin created PR review comment:

Alright, I've gone ahead and find-replaced everything to if-let instead. Thanks for the idea!

view this post on Zulip RFC notifications bot (Apr 26 2022 at 20:38):

cfallin submitted PR review.

view this post on Zulip RFC notifications bot (Apr 26 2022 at 20:38):

cfallin created PR review comment:

Fixed, hopefully clearer now.

view this post on Zulip RFC notifications bot (Apr 26 2022 at 20:38):

cfallin created PR review comment:

Updated, hopefully more descriptive now.

view this post on Zulip RFC notifications bot (Apr 26 2022 at 20:38):

cfallin submitted PR review.

view this post on Zulip RFC notifications bot (Apr 26 2022 at 20:39):

cfallin submitted PR review.

view this post on Zulip RFC notifications bot (Apr 26 2022 at 20:39):

cfallin created PR review comment:

Expanded this with a more explicit discussion of how the evaluation proceeds.

view this post on Zulip RFC notifications bot (Apr 28 2022 at 18:32):

bjorn3 submitted PR review.

view this post on Zulip RFC notifications bot (Apr 28 2022 at 18:32):

bjorn3 submitted PR review.

view this post on Zulip RFC notifications bot (Apr 28 2022 at 18:32):

bjorn3 created PR review comment:

Maybe this should just be (if (magic_simd_extension_enabled))?

view this post on Zulip RFC notifications bot (Apr 28 2022 at 18:35):

cfallin submitted PR review.

view this post on Zulip RFC notifications bot (Apr 28 2022 at 18:35):

cfallin created PR review comment:

Hmm, yeah, that's a nice shorthand. I'll play with this a bit more in the prototype, thanks!

view this post on Zulip RFC notifications bot (Apr 28 2022 at 18:38):

cfallin merged PR #21.

view this post on Zulip RFC notifications bot (Apr 28 2022 at 18:39):

cfallin edited PR #21 from isle-extended-patterns to main:

Rendered

This RFC proposes an extension to the ISLE pattern-matching DSL used by Cranelift's code generation
backends. The extension is a backward-compatible proposal that is meant to make certain lowering
patterns easier to express. The ideas are informed by our experience so far with the DSL, and aim
to replace some awkward uses of extractors with in-arguments with clearer, more direct idioms
using a new language form.

cc @abrown @fitzgen @jlb6740 @akirilov-arm @sparker-arm @uweigand


Last updated: Nov 22 2024 at 17:03 UTC