ashay
commented
2 years ago Based on last night's run, here's the green LLVM commit for this week: ec5def5e20f6ae9fe8cc30e5ee152d4b239e1e95.
However, MHLO is just a tad behind this commit, causing the Torch-MLIR and ONNX-MLIR build to break when I use that commit. Luckily, the patch to MHLO is short. @joker-eph is it possible to get this patch merged into MHLO?
diff --git a/lib/Dialect/mhlo/IR/hlo_ops.cc b/lib/Dialect/mhlo/IR/hlo_ops.cc
index 41a83026..ae41d474 100644
--- a/lib/Dialect/mhlo/IR/hlo_ops.cc
+++ b/lib/Dialect/mhlo/IR/hlo_ops.cc
@@ -715,7 +715,7 @@ void ConstantOp::build(OpBuilder& /*builder*/, OperationState& result,
// All XLA types must be tensor types. In the build() method, we want to
// provide more flexibility by allowing attributes of scalar types. But we
// need to wrap it up with ElementsAttr to construct valid XLA constants.
- type = RankedTensorType::get(/*shape=*/{}, value.getType());
+ type = RankedTensorType::get(/*shape=*/{}, value.cast<TypedAttr>().getType());
value = DenseElementsAttr::get(type.cast<TensorType>(), value);
}
@@ -728,7 +728,7 @@ void ConstantOp::build(OpBuilder& /*builder*/, OperationState& result,
LogicalResult ConstantOp::inferReturnTypes(
MLIRContext*, Optional<Location>, ValueRange, DictionaryAttr attributes,
RegionRange, SmallVectorImpl<Type>& inferredReturnTypes) {
- Type type = attributes.get("value").getType();
+ Type type = attributes.get("value").cast<TypedAttr>().getType();
inferredReturnTypes.push_back(type);
return success();
}
@@ -8758,7 +8758,7 @@ LogicalResult deriveShapeFromOperand(
Operation* MhloDialect::materializeConstant(OpBuilder& builder, Attribute value,
Type type, Location loc) {
// HLO dialect constants require the type of value and result to match.
- if (type != value.getType()) return nullptr;
+ if (type != value.cast<TypedAttr>().getType()) return nullptr;
// HLO dialect constants only support ElementsAttr unlike standard dialect
// constant which supports all attributes.
if (auto elementsAttr = value.dyn_cast<ElementsAttr>())
joker-eph
stephenneuendorffer
sjarus
powderluv
stellaraccident
sstamenova
silvasean
qiuxiafei
Following up on a couple of conversations we've had about coordinating LLVM commits across projects (in onnx-mlir and in LLVM), we had a follow up discussion in the Torch MLIR community meeting yesterday (see this comment for more details).
The short-term solution that we decided to run as an experiment is to use Torch MLIR as the "source of truth" for what commit to use for other projects with the caveat that when the commit of LLVM is chosen for Torch MLIR, it would have gone through some testing that would pretty much guarantee that the commit would satisfy any requirements that onnx-mlir has as well. Based on the discussion, it should be fairly trivial to find a version of MHLO that uses the same LLVM commit as well, though MHLO might need some fixes for onnx-mlir (to make the shared library build work, for example).
We are going to pick the commit based on some internal testing that we do at Microsoft when we pick the LLVM commit that we merge with. This includes several platforms (Ubuntu, Windows, CentOS) and build tools (clang, VS, gcc) and both static and shared library builds. We'll communicate the commit here and we'll use this commit to update Torch MLIR as we are able (though ideally after we communicate the commit someone else will do the update some of the time). Then when it is time for onnx-mlir to update to a newer LLVM commit (which could also be done by us, though ideally not always), that project (as well as any others that want to stay in sync) can choose any of the recent LLVM commits on this list and we'll have at least one point a month where Torch MLIR and onnx-mlir are synced to the same LLVM commit.
The goal is to improve the process for everyone for the short-term while also working on a longer-term solution in LLVM (for example, pre-commit checks, etc.) and this is a relatively cheap first step towards all of these projects being in sync with the same LLVM dependencies.
A second step would be to start tagging the "green" commits automatically (see https://discourse.llvm.org/t/coordinate-llvm-commits-for-different-project/63990/65) instead of "announcing" them manually, but that will require some additional work we need to evaluate.
@AlexandreEichenberger @sjarus @stellaraccident @silvasean @joker-eph @ashay
So to recap:
Let me know if I missed anything or if you have any other questions.