Wasmtime GitHub notifications bot (Nov 08 2023 at 15:53): Wasmtime GitHub notifications bot (Nov 08 2023 at 15:53):fitzgen added the isle label to Issue #7500.
Wasmtime GitHub notifications bot (Nov 08 2023 at 15:53):fitzgen opened issue #7500:
[ ] Instead of having the generated code construct and return an iterator on every call, callers should pass in a reusable vec that gets pushed onto. We use smallvecs right now, which is better than nothing, but once we exceed the inline capacity, we start making lots of temporary allocations.
[ ] We limit the number of rewritten values added to the egraph, and only consider the first 5 values returned by ISLE code:
But the ISLE code still builds up an unbounded number of rewritten values to return. Ideally our rule set would never exhibit this behavior, but it does happen. Since we only take the first N anyways, the generated ISLE code should check if we've reached our max limit (configured at ISLE compile time? or maybe via the context?) and early return instead of spend time matching rewrites whose results will be ignored.
Wasmtime GitHub notifications bot (Nov 08 2023 at 15:54):github-actions[bot] commented on issue #7500:
Subscribe to Label Action
cc @cfallin, @fitzgen
<details>
This issue or pull request has been labeled: "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>
Wasmtime GitHub notifications bot (Nov 13 2023 at 19:56):fitzgen closed issue #7500:
[ ] Instead of having the generated code construct and return an iterator on every call, callers should pass in a reusable vec that gets pushed onto. We use smallvecs right now, which is better than nothing, but once we exceed the inline capacity, we start making lots of temporary allocations.
[ ] We limit the number of rewritten values added to the egraph, and only consider the first 5 values returned by ISLE code:
But the ISLE code still builds up an unbounded number of rewritten values to return. Ideally our rule set would never exhibit this behavior, but it does happen. Since we only take the first N anyways, the generated ISLE code should check if we've reached our max limit (configured at ISLE compile time? or maybe via the context?) and early return instead of spend time matching rewrites whose results will be ignored.
Last updated: Nov 22 2024 at 16:03 UTC