scottmcm opened PR #7615 from scottmcm:spaceship
to bytecodealliance:main
:
I was writing a pattern for Rust's
Ord::cmp
(context zulip thread)And noticed that the
if *self == *other { Equal } else { Greater }
part isif c { false } else { true }
.So here's a smaller PR with some simpler sub-patterns first.
scottmcm requested elliottt for a review on PR #7615.
scottmcm requested wasmtime-compiler-reviewers for a review on PR #7615.
scottmcm submitted PR review.
scottmcm created PR review comment:
Is the duplicated rules -- one for I8, one for wider -- the best way to do this? Or is there a
uextend-if-needed
that one rule could produce?
github-actions[bot] commented on PR #7615:
Subscribe to Label Action
cc @cfallin, @fitzgen
<details>
This issue or pull request has been labeled: "cranelift", "isle"Thus the following users have been cc'd because of the following labels:
- cfallin: isle
- fitzgen: isle
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
alexcrichton submitted PR review.
alexcrichton created PR review comment:
There's various little helpers around and I'm not super familiar with these ISLE files, but it's fine to add a helper for this. I'd also recommend doing that because this rule you've commented on will produce invalid CLIF if
sty
is$I8
becauseuextend
is only valid of the output type is larger than the input type.A small helper along the lines of this though would fix it:
(decl uextend_to_ty (Type Value) Value) (rule 0 (uextend_to_ty ty val) (uextend ty val)) (rule 1 (uextend_to_ty $I8 val) val)
alexcrichton submitted PR review.
alexcrichton created PR review comment:
To further expand on this a bit as well, what you've defined here are effectively two overlapping rules, for example the rule on line 23 (this one) and the rule on line 13 (the i8 case above). For an i8-producing-select both rules match, and I believe ISLE allows that for the "multi" constructor that
simplify
is (since I believe it's generating all matches and yielding them to the egraph driver). While the above rule is "lower cost" and will get selected eventually I think it's probably still best to avoid the possibility of accidentally creating invalid CLIF
scottmcm submitted PR review.
scottmcm created PR review comment:
Ah, got it. When having the
$I8
pattern meant that the tests worked for both widths, I didn't know if that meant it was treated as "more specific" or something.I'll add (or find) a helper for this. I agree having the useless-and-invalid
extend
option in the graph isn't good.
scottmcm updated PR #7615.
alexcrichton submitted PR review.
alexcrichton has enabled auto merge for PR #7615.
scottmcm submitted PR review.
scottmcm created PR review comment:
Thanks! I couldn't find any similar existing rule, but the one you provided worked great.
alexcrichton merged PR #7615.
Last updated: Nov 22 2024 at 17:03 UTC