Connect the hoistRedundantVectorTransfers functionality to the transform
dialect.
Authored-by: Quentin Colombet <quentin.colombet@gmail.com>
Differential Revision: https://reviews.llvm.org/D144260
This patch adds atof, strtof, strtod, and strtold to the bazel build, as
well as their tests.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D144140
This change adds a new `SparseTensorType` class for making the "dim" vs "lvl" distinction more overt, and for abstracting over the differences between sparse-tensors and dense-tensors. In addition, this change also adds new type aliases `Dimension`, `Level`, and `FieldIndex` to make code more self-documenting.
Although the diff is very large, the majority of the changes are mechanical in nature (e.g., changing types to use the new aliases, updating variable names to match, etc). Along the way I also made many variables `const` when they could be; the majority of which required only adding the keyword. A few places had conditional definitions of these variables, requiring actual code changes; however, that was only done when the overall change was extremely local and easy to extract. All these changes are included in the current patch only because it would be too onerous to split them off into a separate patch.
Reviewed By: aartbik
Differential Revision: https://reviews.llvm.org/D143800
Make `tosa.apply_scale` implement `VectorUnrollOpInterface` so that we
can unroll it.
Reviewed By: rsuderman
Differential Revision: https://reviews.llvm.org/D143944
`alloc`s that have users outside of loops are guaranteed to fail in
`multibuffer`.
Instead of exposing ourselves to that failure in the transform dialect,
filter out the `alloc`s that fall in this category.
To be able to do this filtering we have to change the `multibuffer`
transform op from `TransformEachOpTrait` to a plain `TransformOp`. This is
because `TransformEachOpTrait` expects that every successful `applyToOne`
returns a non-empty result.
Couple of notes:
- I changed the assembly syntax to make sure we only get `alloc` ops as
input. (And added a test case to make sure we reject invalid inputs.)
- `multibuffer` can still fail pretty easily when you know its limitations.
See the updated `op failed to multibuffer` test case for instance.
Longer term, instead of leaking/coupling the actual implementation (in
this case the checks normally done in `memref::multiBuffer`) with the
transform dialect (the added check in `::apply`), we may want to refactor
how we structure the underlying implementation. E.g., we could imagine a
`canApply` method for all the implementations that we want to hook up in
the transform dialect.
This has some implications on how not to duplicate work between
`canApply` and the actual implementation but I thought I throw that here
to have us think about it :).
Differential Revision: https://reviews.llvm.org/D143747
Properly set floating point exceptions and add more exceptional
values for non-FMA x86-64 targets.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D143699
