You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the type system designed in #104, we need to create the system that will convert from opaque MLIR types to explicit Verona dialect types. This will likely incur in inter-procedural analysis and may need to generate multiple copies of the same function with different types.
We'd want to keep those auto-generate functions in sync, or at least related to each other with some form of annotation (ex. from which base function they're derived, other sibling stubs) and we may need to more aggressively inline or elide those auto-generated functions.
We could implement this as a precursor of the partial conversion (opaque -> Verona), so that the lowering happens in a more natural way, or we could make that as part of the lowering, but we need to be careful with partially lowered types and stubs. In any case, we'll need a cleanup pass before validation.
The initial support is critical to get right, with the remaining support included as it's added, later in the process.
Acceptance criteria:
Generate complete explicit Verona types from existing opaque MLIR types for existing examples
Tests covering expected types from opaque ones
Not included:
Full language support for all possible types
The text was updated successfully, but these errors were encountered:
With the type system designed in #104, we need to create the system that will convert from opaque MLIR types to explicit Verona dialect types. This will likely incur in inter-procedural analysis and may need to generate multiple copies of the same function with different types.
We'd want to keep those auto-generate functions in sync, or at least related to each other with some form of annotation (ex. from which base function they're derived, other sibling stubs) and we may need to more aggressively inline or elide those auto-generated functions.
We could implement this as a precursor of the partial conversion (opaque -> Verona), so that the lowering happens in a more natural way, or we could make that as part of the lowering, but we need to be careful with partially lowered types and stubs. In any case, we'll need a cleanup pass before validation.
The initial support is critical to get right, with the remaining support included as it's added, later in the process.
Acceptance criteria:
Not included:
The text was updated successfully, but these errors were encountered: