mmcloughlin opened PR #8761 from mmcloughlin:mbm/isle-binding-make-some
to bytecodealliance:main
:
Work-in-progress PR to demonstrate an idea for discussion.
When working with the ISLE "trie again" representation there is an awkward detail with partial internal constructors. Specifically, the result binding in the rule will refer to an expression of type
T
, while the return type of the generated constructor is typeOption<T>
. The wrapping of the return expression inSome(..)
happens at codegen when the return kind isReturnKind::Option
.This presents an incompatibility when implementing inlining at the trie level. If a constructor binding is selected for inlining then all the bindings for the rule application are imported, and the constructor callsite is replaced with the result binding. Therefore the result of inlining replaces a binding of type
Option<T>
with one of typeT
and the result is invalid. To fix this we just need to figure out where the right place is to insert theSome(..)
wrapper.This PR offers one approach to add a
Binding::MakeSome
variant and materialize theSome(..)
wrapping in the trie. Note we already haveBinding::{Match,Make}Variant
andBinding::MatchSome
soBinding::MakeSome
is a natural addition. The rule set builder is expanded to wrap the result binding in MakeSome for partial constructors. With this change theSome(..)
wrapper in codegen is no longer needed, and the inlining problem mentioned above goes away.
github-actions[bot] commented on PR #8761:
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>
mmcloughlin edited PR #8761:
When working with ISLE's "trie again" representation there is an awkward detail with partial internal constructors. The result binding of a rule will refer to an expression of type
T
, while the return type of the generated constructor is typeOption<T>
. The wrapping of the return expression inSome(..)
happens at codegen when the return kind isReturnKind::Option
.This presents an incompatibility when implementing inlining at the trie level. If a constructor binding is selected for inlining then all the bindings for the rule application are imported, and the constructor callsite is replaced with the result binding. Therefore the result of inlining replaces a binding of type
Option<T>
with one of typeT
and the result is invalid. To fix this we just need to figure out where the right place is to insert theSome(..)
wrapper.This PR offers one approach to add a
Binding::MakeSome
variant and materialize theSome(..)
wrapping in the trie. Note we already haveBinding::{Match,Make}Variant
andBinding::MatchSome
soBinding::MakeSome
is a natural addition. The rule set builder is expanded to wrap the result binding in MakeSome for partial constructors. With this change theSome(..)
wrapper in codegen is no longer needed, and the inlining problem mentioned above goes away.
Last updated: Dec 23 2024 at 12:05 UTC