Skip to content

cranelift-isle: New IR and revised overlap checks #5195

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 15 commits into from
Nov 14, 2022

Conversation

jameysharp
Copy link
Contributor

I've replaced the overlap checker with one that uses my new IR for ISLE. This is a step toward using the new IR for codegen too. This step gives me some confidence in the correctness of the IR construction without having to get all the codegen details right yet.

This isn't quite ready to merge yet, but it's at a milestone where I think it should pass CI, so I thought folks like @elliottt or @fitzgen might want to take a look.

@github-actions github-actions bot added cranelift Issues related to the Cranelift code generator isle Related to the ISLE domain-specific language labels Nov 4, 2022
@github-actions
Copy link

github-actions bot commented Nov 4, 2022

Subscribe to Label Action

cc @cfallin, @fitzgen

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 .github/subscribe-to-label.json configuration file.

Learn more.

@@ -102,6 +102,7 @@ pub mod overlap;
pub mod parser;
pub mod sema;
pub mod trie;
pub mod trie_again;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤣

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jameysharp jameysharp marked this pull request as ready for review November 4, 2022 21:27
@jameysharp
Copy link
Contributor Author

Printing errors with Miette is crashing for me, and quoting way too much of the source code when it doesn't crash, and I don't understand why.

But I'm disabling the new "rule shadowed by more general higher-priority rule" errors anyway because I want to merge this before fixing them in the backends. Anyway, builds don't normally turn on Miette, so I'm hoping to merge this without getting Miette exactly right.

Otherwise I think this is ready to merge so I'd appreciate review.

By the way, the number of rules which currently can't fire due to higher-priority rules always matching first is:

  • 25 in aarch64
  • 12 in x64
  • 4 in s390x
  • 0 in riscv64

Apparently there aren't any rules in any backends which attempt to constrain a binding site in two incompatible ways, like (and 1 2), so that's reassuring.

@jameysharp
Copy link
Contributor Author

I have a plausible hypothesis about why I was having trouble with Miette. The Error::Errors case, which contains a Vec<Error>, is handled in error_miette.rs by returning all the errors from miette::Diagnostic::related. I think Miette is then trying to report the source code for a span containing all of those errors at once. I think the panic I saw was when different errors came from different source files, so it couldn't cover them all in one span.

Rather than fix any of that right now, I've just removed all my attempts to use Miette "properly" in this PR. Instead, the new errors are reported with basically the same simple text formatting whether Miette is enabled or not.

Copy link
Member

@cfallin cfallin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for chasing this idea -- this seems really really promising! Overall this is a really clean implementation.

I only started to get a bit confused when reading through normalize_equivalence_classes and I'm wondering if there's a better way; at the very least, the implementation needs to be explained a lot better. But with that fixed, the rest LGTM.

@jameysharp
Copy link
Contributor Author

As a data point, this PR has passed about 11 million executions of ISLE's fuzzer (when combined with #5236).

Copy link
Member

@cfallin cfallin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! I went over this with Jamey just now in a pair-review and managed to wrap my brain around it all -- it's pretty subtle in places but all seems correct. Just some requests for more detailed comments in a few places but otherwise good to merge.

I had tried to use Miette "right" and made things worse somehow. Among
other changes, revert all my changes to unrelated parts of `error.rs`
and `error_miette.rs`.
This saves about 50 lines of code in the trie_again module. The
union-find implementation is about twice as long as that, counting
comments and doc-tests, but that's a worth-while tradeoff.

However, this makes `normalize_equivalence_classes` slower, because now
finding all elements of an equivalence class takes time linear in the
total size of all equivalence classes. If that ever turns out to be a
problem in practice we can find some way to optimize `remove_set_of`.
We want to enforce that consumers of this representation can't observe
non-deterministic ordering in any of its public types.
I'm not sure whether this is a good idea. It doesn't make the logic
particularly simpler, and I think it will do more work if three or more
binding sites with enum-variant constraints get set equal to each other.
@jameysharp jameysharp enabled auto-merge (squash) November 14, 2022 01:48
@jameysharp jameysharp merged commit 70c72ee into bytecodealliance:main Nov 14, 2022
@jameysharp jameysharp deleted the isle-new-ir branch November 14, 2022 19:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cranelift Issues related to the Cranelift code generator isle Related to the ISLE domain-specific language
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants