Tags: Rezamatin1365/torch-mlir
Tags
Advance llvm-project and stablehlo. (llvm#2619) llvm-project: bbd2b08 stablehlo: ab709fe48de88c67717abfbd7ef17425eb95ddaf These commits were chosen in order to account for an MLIR API break from llvm/llvm-project@3dbac2c which required a patch to stablehlo. We integrate a bit beyond that commit to deal with some revert/reapply cycles in the intervening range which were discovered in another downstream. Further, it requires adaptation to the stablehlo API breaks introduced from openxla/stablehlo#1872 which are along for the ride. Since some stablehlo builders were changed to directly take int64_t array refs, also traced that up some call stacks to eliminate some signed/unsigned mismatches that result. Also adds a few TOSA tests to the passing set that seem to work now.
[TorchToLinalg] Fix integer type handling for aten.mm (llvm#2615) Despite aten.mm requiring the input and output types match, we still opt to maintain signedness semantics in case later passes try to do any sort of integer type narrowing.
Regenerate GeneratedTorchOps.td after recent change to torch_ods_gen.… …py (llvm#2612) Try to fix the error reported by @qingyunqu in llvm#2609.
build: manually update PyTorch version Set PyTorch and TorchVision version to nightly release 2023-12-04. Signed-Off By: Vivek Khandelwal <vivekkhandelwal1424@gmail.com>
[TorchToLinalg] NFC: Move Utils.h to an externally accessible location ( llvm#2603)
[TorchToLinalg] NFC: Move Utils.h to an externally accessible location ( llvm#2603)
[TorchToLinalg] NFC: Move Utils.h to an externally accessible location ( llvm#2603)
Move handling of integer signedness to the backend conversions (llvm#… …2597) The function `getTypeForScalarType` currently takes an argument to specify the signedness of integer types. This is leakage of backend specific requirements into the torch dialect world. Because `getTypeForScalarType` is a utility function for the torch dialect, it should only produce types that match the sign conventions used by PyTorch (regular integers are signed and unsigned integers are unsigned). This commit removes the signedness argument from `getTypeForScalarType`, and moves the backend specific handling of integer types to the backend code.
Move handling of integer signedness to the backend conversions (llvm#… …2597) The function `getTypeForScalarType` currently takes an argument to specify the signedness of integer types. This is leakage of backend specific requirements into the torch dialect world. Because `getTypeForScalarType` is a utility function for the torch dialect, it should only produce types that match the sign conventions used by PyTorch (regular integers are signed and unsigned integers are unsigned). This commit removes the signedness argument from `getTypeForScalarType`, and moves the backend specific handling of integer types to the backend code.
Bump LLVM and StableHLO (llvm#2598) Bump LLVM to `5e5a22caf88ac1ccfa8dc5720295fdeba0ad9372` and StableHLO to `83f095e7217c897f1eccac5652600ceb944cb0e0`. Bazel GHA: https://github.com/sjain-stanford/torch-mlir/actions/runs/7027647674
PreviousNext