Wasmtime GitHub notifications bot (Sep 13 2022 at 16:16): Wasmtime GitHub notifications bot (Sep 13 2022 at 16:16):elliottt opened PR #4906 from trevor/isle-overlap-checker to main:
<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
Wasmtime GitHub notifications bot (Sep 13 2022 at 17:02):elliottt updated PR #4906 from trevor/isle-overlap-checker to main.
Wasmtime GitHub notifications bot (Sep 13 2022 at 17:12):elliottt edited PR #4906 from trevor/isle-overlap-checker to main:
Introduce overlap checking for ISLE as the start of addressing #4717.
The overlap checker detects cases where ISLE rules could fire for the same input. Consider the following example from the x64 lowerings (line numbers added for clarity):
1: (rule (sse_xor_op $F32X4) (SseOpcode.Xorps)) 2: (rule (sse_xor_op $F64X2) (SseOpcode.Xorpd)) 3: (rule (sse_xor_op (multi_lane _bits _lanes)) (SseOpcode.Pxor))Rule 3 overlaps separately with rules 1 and 2, but rules 1 and 2 don't overlap with each other. With overlap checking enabled this will be reported as an overlap of all three rules, where the rule on line 3 will be identified as the source of the overlap (error messages could definitely be improved here). In this case the overlap can be resolved by setting a lower priority for rule 3.
For another example, consider the following:
1: (rule (example $F32 25) ...) 2: (rule (example $F32 (fallible_extractor y)) ...) 3: (rule (example $F64 _) ...)In this case, only the rules on lines 1 and 2 overlap, as we don't know that the fallible extractor won't fire successfully on the input
25. As the rule on line 3 has a different leading pattern ($F64) it won't be part of the overlap group generated.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
- [ ] This has been discussed in issue #..., or if not, please tell us why
here.- [ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.- [ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
Wasmtime GitHub notifications bot (Sep 13 2022 at 17:14):elliottt edited PR #4906 from trevor/isle-overlap-checker to main:
Introduce overlap checking for ISLE as the start of addressing #4717.
The overlap checker detects cases where ISLE rules could fire for the same input. Consider the following example from the x64 lowerings (line numbers added for clarity):
1: (rule (sse_xor_op $F32X4) (SseOpcode.Xorps)) 2: (rule (sse_xor_op $F64X2) (SseOpcode.Xorpd)) 3: (rule (sse_xor_op (multi_lane _bits _lanes)) (SseOpcode.Pxor))Rule 3 overlaps separately with rules 1 and 2, but rules 1 and 2 don't overlap with each other. With overlap checking enabled this will be reported as an overlap of all three rules, where the rule on line 3 will be identified as the source of the overlap (error messages could definitely be improved here). In this case the overlap can be resolved by setting a lower priority for rule 3.
For another example, consider the following:
1: (rule (example $F32 25) ...) 2: (rule (example $F32 (fallible_extractor y)) ...) 3: (rule (example $F64 _) ...)In this case, only the rules on lines 1 and 2 overlap, as we don't know that the fallible extractor won't fire successfully on the input
25. As the rule on line 3 has a different leading pattern ($F64) it won't be part of the overlap group generated.However, if the example looks instead like the following:
1: (rule (example $F32 (fallible_extractor 25)) ...) 2: (rule (example $F32 (fallible_extractor 31)) ...) 3: (rule (example $F64 _) ...)We consider there to be no overlap in the rules as fallible extractors are expected to be pure.
<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
- [ ] This has been discussed in issue #..., or if not, please tell us why
here.- [ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.- [ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
Wasmtime GitHub notifications bot (Sep 13 2022 at 17:14):elliottt requested cfallin for a review on PR #4906.
Wasmtime GitHub notifications bot (Sep 13 2022 at 17:14):elliottt has marked PR #4906 as ready for review.
Wasmtime GitHub notifications bot (Sep 13 2022 at 17:15):elliottt created PR review comment:
This is not the most helpful error output, but I'm assuming that as we start burning down the list of overlaps we'll figure out what's most useful to identify.
Wasmtime GitHub notifications bot (Sep 13 2022 at 17:15):elliottt submitted PR review.
Wasmtime GitHub notifications bot (Sep 13 2022 at 17:17):elliottt edited PR #4906 from trevor/isle-overlap-checker to main:
Introduce overlap checking for ISLE as the start of addressing #4717.
The overlap checker detects cases where ISLE rules could fire for the same input. Consider the following example from the x64 lowerings (line numbers added for clarity):
13: (rule (sse_xor_op $F32X4) (SseOpcode.Xorps)) 14: (rule (sse_xor_op $F64X2) (SseOpcode.Xorpd)) 15: (rule (sse_xor_op (multi_lane _bits _lanes)) (SseOpcode.Pxor))Rule 15 overlaps separately with rules 13 and 14, but rules 13 and 14 don't overlap with each other. With overlap checking enabled this will be reported as an overlap of all three rules, where the rule on line 15 will be identified as the source of the overlap (error messages could definitely be improved here). In this case the overlap can be resolved by setting a lower priority for rule 3.
Error: × overlap error: rules are overlapping │ ../x64.isle:15:0 │ ../x64.isle:13:0 │ ../x64.isle:14:0For another example, consider the following:
1: (rule (example $F32 25) ...) 2: (rule (example $F32 (fallible_extractor y)) ...) 3: (rule (example $F64 _) ...)In this case, only the rules on lines 1 and 2 overlap, as we don't know that the fallible extractor won't fire successfully on the input
25. As the rule on line 3 has a different leading pattern ($F64) it won't be part of the overlap group generated.However, if the example looks instead like the following:
1: (rule (example $F32 (fallible_extractor 25)) ...) 2: (rule (example $F32 (fallible_extractor 31)) ...) 3: (rule (example $F64 _) ...)We consider there to be no overlap in the rules as fallible extractors are expected to be pure.
<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
- [ ] This has been discussed in issue #..., or if not, please tell us why
here.- [ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.- [ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
Last updated: Nov 22 2024 at 16:03 UTC