Fork Attributes and Types for VHLO #849
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
GleasonK
force-pushed
the
compat-fork-attrtype
branch
from
538277d
to
33a7e73
Compare
burmako
suggested changes
Dec 29, 2022
GleasonK
force-pushed
the
compat-fork-attrtype
branch
4 times, most recently
from
62dfef2
to
aac4a00
Compare
GleasonK
force-pushed
the
compat-fork-attrtype
branch
from
aac4a00
to
e9e5153
Compare
burmako
suggested changes
Jan 20, 2023
GleasonK
force-pushed
the
compat-fork-attrtype
branch
from
591dcb2
to
0560b4a
Compare
burmako
suggested changes
Jan 26, 2023
GleasonK
force-pushed
the
compat-fork-attrtype
branch
from
8aeb8b9
to
99cc04e
Compare
GleasonK
force-pushed
the
compat-fork-attrtype
branch
from
67ae8ae
to
2162f56
Compare
burmako
suggested changes
Feb 1, 2023
GleasonK
force-pushed
the
compat-fork-attrtype
branch
from
6899f46
to
0ccd322
Compare
burmako
suggested changes
Feb 3, 2023
burmako
reviewed
Feb 3, 2023
burmako
approved these changes
Feb 3, 2023
burmako
pushed a commit
that referenced
this pull request
Feb 8, 2023
I recently noticed this code when reviewing #849, and I'm not sure why we need it there. This seems like a pretty strong statement about a fundamental role of the Tensor dialect in the workings of the StableHLO dialect, and I don't think we have established that yet. It would seem that we've inherited this from MHLO when bootstrapping StableHLO (#1), but I don't think I understand the reasoning on the MHLO side either. This change was introduced as part of an LLVM integrate (tensorflow/mlir-hlo@ba0346b), and the commit description doesn't go into detail about motivation. Given that, I propose to revert this in the StableHLO dialect and see what happens. All tests in this repository are passing, but maybe we'll learn more after downstream integrations.
GleasonK
pushed a commit
to GleasonK/stablehlo
that referenced
this pull request
Feb 8, 2023
) I recently noticed this code when reviewing openxla#849, and I'm not sure why we need it there. This seems like a pretty strong statement about a fundamental role of the Tensor dialect in the workings of the StableHLO dialect, and I don't think we have established that yet. It would seem that we've inherited this from MHLO when bootstrapping StableHLO (#1), but I don't think I understand the reasoning on the MHLO side either. This change was introduced as part of an LLVM integrate (tensorflow/mlir-hlo@ba0346b), and the commit description doesn't go into detail about motivation. Given that, I propose to revert this in the StableHLO dialect and see what happens. All tests in this repository are passing, but maybe we'll learn more after downstream integrations.
GleasonK
added a commit
to GleasonK/stablehlo
that referenced
this pull request
Feb 10, 2023
- Change `CustomCallApiVersion` to an enum instead of an integer value. + To avoid transforming _all_ integers, the transformation from StableHLO --> VHLO special cases this conversion - Attributes + Forked Attributes: `IntegerAttr, StringAttr, UnitAttr, ArrayAttr`, `DenseIntOrFPElementsV1Attr, FlatSymbolRefV1Attr, FloatV1Attr` - Types + Forked Types: `RankedTensorType, UnrankedTensorType, TupleType, WitnessType`, `BFloat16V1Type, Float16V1Type, Float32V1Type, Float64V1Type, IndexV1Type, ComplexV1Type, IntegerV1Type, UniformQuantizedV1Type` - Bytecode implementations forked from [BuiltinDialectBytecode.cpp](https://github.com/llvm/llvm-project/blob/c48e0cf03a50bb8a2043ac4bb5e9a83ff135247a/mlir/lib/IR/BuiltinDialectBytecode.cpp)
GleasonK
pushed a commit
to GleasonK/stablehlo
that referenced
this pull request
Feb 10, 2023
) I recently noticed this code when reviewing openxla#849, and I'm not sure why we need it there. This seems like a pretty strong statement about a fundamental role of the Tensor dialect in the workings of the StableHLO dialect, and I don't think we have established that yet. It would seem that we've inherited this from MHLO when bootstrapping StableHLO (#1), but I don't think I understand the reasoning on the MHLO side either. This change was introduced as part of an LLVM integrate (tensorflow/mlir-hlo@ba0346b), and the commit description doesn't go into detail about motivation. Given that, I propose to revert this in the StableHLO dialect and see what happens. All tests in this repository are passing, but maybe we'll learn more after downstream integrations.
atondwal
pushed a commit
to atondwal/stablehlo
that referenced
this pull request
Mar 3, 2023
- Change `CustomCallApiVersion` to an enum instead of an integer value. + To avoid transforming _all_ integers, the transformation from StableHLO --> VHLO special cases this conversion - Attributes + Forked Attributes: `IntegerAttr, StringAttr, UnitAttr, ArrayAttr`, `DenseIntOrFPElementsV1Attr, FlatSymbolRefV1Attr, FloatV1Attr` - Types + Forked Types: `RankedTensorType, UnrankedTensorType, TupleType, WitnessType`, `BFloat16V1Type, Float16V1Type, Float32V1Type, Float64V1Type, IndexV1Type, ComplexV1Type, IntegerV1Type, UniformQuantizedV1Type` - Bytecode implementations forked from [BuiltinDialectBytecode.cpp](https://github.com/llvm/llvm-project/blob/c48e0cf03a50bb8a2043ac4bb5e9a83ff135247a/mlir/lib/IR/BuiltinDialectBytecode.cpp)
atondwal
pushed a commit
to atondwal/stablehlo
that referenced
this pull request
Mar 3, 2023
) I recently noticed this code when reviewing openxla#849, and I'm not sure why we need it there. This seems like a pretty strong statement about a fundamental role of the Tensor dialect in the workings of the StableHLO dialect, and I don't think we have established that yet. It would seem that we've inherited this from MHLO when bootstrapping StableHLO (openxla#1), but I don't think I understand the reasoning on the MHLO side either. This change was introduced as part of an LLVM integrate (tensorflow/mlir-hlo@ba0346b), and the commit description doesn't go into detail about motivation. Given that, I propose to revert this in the StableHLO dialect and see what happens. All tests in this repository are passing, but maybe we'll learn more after downstream integrations.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
CustomCallApiVersionto an enum instead of an integer value.IntegerAttr, StringAttr, UnitAttr, ArrayAttr,DenseIntOrFPElementsV1Attr, FlatSymbolRefV1Attr, FloatV1AttrRankedTensorType, UnrankedTensorType, TupleType, WitnessType,BFloat16V1Type, Float16V1Type, Float32V1Type, Float64V1Type, IndexV1Type, ComplexV1Type, IntegerV1Type, UniformQuantizedV1TypeNeed a closer review on FloatAttr since it deals with numerics, I have a FIXME comment next to that line still. I may revert from forking that value so that the implementation doesn't have to deal with numeric value conversions.
Closes #674.