Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Type promotion in DaphneDSL #364

Open
pdamme opened this issue May 15, 2022 · 0 comments
Open

Type promotion in DaphneDSL #364

pdamme opened this issue May 15, 2022 · 0 comments
Assignees
@pdamme

Comments

@pdamme
Copy link
Collaborator

pdamme commented May 15, 2022

DaphneDSL still has several limitations regarding the combination of values of different data/value types. I'm going to address them in roughly the following steps:

  • Type inference shall support type promotion (e.g., si64 plus f64 shall be f64, matrix<si64> plus f32 shall be matrix<fp32>, etc.). For that purpose, type inference shall be based on traits for typical cases (as an alternative to the existing interface), akin to shape inference.
  • A compiler pass harmonizing argument types of operations, to avoid an exponential explosion of the kernel instantiations to generate, while still being (becoming) able to process any argument type combination. For instance, si64 plus f64 shall cast the first argument to f64.
  • More flexible instantiation of kernels with op codes. It should be possible to specify different type combinations (result, arguments) for different sets of op codes.

This should also fix some other issues:
pdamme added a commit that referenced this issue May 15, 2022
@pdamme
[DAPHNE-#364] Harmonized type inference with shape inference.
444d9e1 
- This is a preparation step for upcoming improvements to type inference (type promotion etc.).
- Type inference interface returns a std::vector<mlir::Type>, not void.
- Added a tryInferType function.
  - Currently checks only for the type inference interface.
  - Will check for type inference traits in the future.
- Refactored existing type inference interface implementations to return std::vector<mlir::Type>.
- Adapted InferencePass accordingly.
- A little fix regarding type inference for AllAggOp.
- Contributes to #364.
@pdamme pdamme self-assigned this May 15, 2022
pdamme added a commit that referenced this issue May 27, 2022
@pdamme
[DAPHNE-#364] Harmonized type inference with shape inference.
46ecad6 
- This is a preparation step for upcoming improvements to type inference (type promotion etc.).
- Type inference interface returns a std::vector<mlir::Type>, not void.
- Added a tryInferType function.
  - Currently checks only for the type inference interface.
  - Will check for type inference traits in the future.
- Refactored existing type inference interface implementations to return std::vector<mlir::Type>.
- Adapted InferencePass accordingly.
- A little fix regarding type inference for AllAggOp.
- Contributes to #364.
pdamme added a commit that referenced this issue May 27, 2022
@pdamme
[DAPHNE-#364] Allowing Unknown-type inputs/outputs in DaphneIR ops.
25787d7 
- DaphneIR has the Unknown type to indicate that the type of some value is not known yet.
- However, typical type constraints on the inputs/outputs of DaphneIR ops prevented its use in many cases.
- Now, Unknown is allowed in almost all cases where more than a single type is allowed for an input/output.
- This was achieved as follows:
  - Added Unknown to he definitions of our own sets of types (e.g., IntScalar) (which are expressed via AnyTypeOf).
  - Added Unknown to all occurrences of AnyTypeOf.
  - Instead of Matrix/Frame we now use the custom type constraints MatrixOrU/FrameOrU.
- This change doesn't have any effects right now, but simplifies further work on type inference.
@pdamme pdamme mentioned this issue Jun 4, 2022
Merged
@aristotelis96 aristotelis96 mentioned this issue Jun 6, 2022
Closed
pdamme added a commit that referenced this issue Oct 14, 2022
@pdamme
[DAPHNE-#364] Harmonized type inference with shape inference.
073da20 
- This is a preparation step for upcoming improvements to type inference (type promotion etc.).
- Type inference interface returns a std::vector<mlir::Type>, not void.
- Added a tryInferType function.
  - Currently checks only for the type inference interface.
  - Will check for type inference traits in the future.
- Refactored existing type inference interface implementations to return std::vector<mlir::Type>.
- Adapted InferencePass accordingly.
- A little fix regarding type inference for AllAggOp.
- Contributes to #364.
pdamme added a commit that referenced this issue Oct 14, 2022
@pdamme
[DAPHNE-#364] Allowing Unknown-type inputs/outputs in DaphneIR ops.
2e60b08 
- DaphneIR has the Unknown type to indicate that the type of some value is not known yet.
- However, typical type constraints on the inputs/outputs of DaphneIR ops prevented its use in many cases.
- Now, Unknown is allowed in almost all cases where more than a single type is allowed for an input/output.
- This was achieved as follows:
  - Added Unknown to he definitions of our own sets of types (e.g., IntScalar) (which are expressed via AnyTypeOf).
  - Added Unknown to all occurrences of AnyTypeOf.
  - Instead of Matrix/Frame we now use the custom type constraints MatrixOrU/FrameOrU.
- This change doesn't have any effects right now, but simplifies further work on type inference.
- Contributes to #364.
pdamme added a commit that referenced this issue Oct 14, 2022
@pdamme
[DAPHNE-#364] Type inference traits for the majority of DaphneIR ops.
e89f47d 
- Introduced various traits for common cases of type inference.
- Attached suitable traits to the majority of the DaphneIR ops.
- These traits are used during the type inference compiler pass (the type inference function tryInferType() takes these traits into account).
- Removed many type inference interface implementations, since they are now covered by traits in a very concise way.
- For several ops, type inference is so special that it cannot handled by reusable traits (which is totally fine). These must implement the type inference interface; but at the moment, many of those simply throw an exception (will be addressed later).
- Note that the parser and passes still do type inference on their own when they create new ops (this will be addressed later).
- Lots of unit test cases for type inference based on traits.
- Contributes to #364.
pdamme added a commit that referenced this issue Oct 14, 2022
@pdamme
[DAPHNE-#364] The DaphneDSL parser uses the new type inference for ma…
c698d73 
…ny operations.

- Introduced a central function for setting the infered types: setInferedTypes().
  - This is used by both the DaphneDSL parser and the inference pass.
- Instead of doing its own type inference, the DaphneDSL parser creates many operations with an unknown result type and applies the compiler's type inference immediately.
pdamme added a commit that referenced this issue Oct 14, 2022
@pdamme
[DAPHNE-#364] Relaxed value type contraints on many ops.
b56a77f 
- This is to give type inference/promotion more freedom.
- So far, many operations were restricted to floating-point value types, thereby prohibiting even their creation with integers.
- However, with the new type inference/promotion, we can also use them with other numerical types, especially integers.
pdamme added a commit that referenced this issue Oct 14, 2022
@pdamme
[DAPHNE-#364] Added type inference for idxMin/idxMax.
8f028ba 
- Their result is always a matrix of value type Size.
- Added a respective type inference trait.
pdamme added a commit that referenced this issue Oct 14, 2022
@pdamme
[DAPHNE-#364] Introduced AdaptTypesToKernelsPass.
0372407 
- A new compiler pass that runs after (type) inference and before lowering to kernel calls.
- Adapts the input/output types of operations to match available pre-compiled kernels.
  - Current implementation is very simple: Just ensures that all inputs have the same value type as the output, by introducing casts where necessary.
- Operation traits telling this pass which ops to process.
- Assigned these traits to several (classes of) ops.
- More instantiations of cast kernels (especially for IndexType).
- Lots of script-level test cases.
pdamme added a commit that referenced this issue Oct 14, 2022
@pdamme
[DAPHNE-#364] Explanation of AdaptTypesToKernelsPass.
3797297 
- The resulting IR of this pass can be printed/explained.
- New user config item (at all levels from files to CLI arg) for this.
- New value for --explain CLI arg: type_adaptation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@pdamme pdamme

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@pdamme