Comments (5)
I'm sorry I didn't participate in the meeting. I can't offer any constructive suggestions.
from mlir-hlo.
StableHLO will be a purely interchange format as positioned at the moment yes (e.g., no transformations on it). Given the goal of stable interchange, it should be easy to vendor, provides some backward and forward compatibility (at least in conjunction with MLIR bytecode format, not APIs yet, details TBD), and reduce the hard code linkage (e.g., it could enable decoupling some of the coordination of git rev bumping).
Targeting StableHLO rather than MHLO from ONNX has some advantages. And for first while, the switch could be at "sed" level. I would suggest waiting a little bit until there is a clearer signal here and then doing cost-benefit analysis. But goal is to reduce cost for frontends/interchange only interops. [I'm very excited about bytecode, I think it'll flush out some issues here too, but I'd let things bake a bit until "desired temperature" before incurring cost - while in same breath I should add that unstable interop is an ongoing cost]
from mlir-hlo.
Thank you, Jacques! I agree that it is prudent to experiment with StableHLO before making the decision either way, and I'd love to assist however I can.
In the next 2-3 weeks, we're planning to turn StableHLO into a drop-in replacement for MHLO by adding the currently missing Python bindings and Bazel build, introducing the StableHLO <=> MHLO conversion, and then landing all that in MLIR-HLO. (More details in https://github.com/openxla/stablehlo/issues).
Once that happens, experimenting with StableHLO will be as easy as changing the CMake/Bazel target you depend on (from MHLO to StableHLO) and making some textual replacements. By that time, I expect we'll also have the stability guarantees documented, so that it is clear what the users can rely upon.
As far as the current positioning goes (e.g. the "no transformations" part), this is a fairly new area for all of us, so there is still quite a bit of flexibility. E.g. if it becomes apparent that it would be beneficial for StableHLO to support transformations, then we could revisit this. I imagine that a good way of validating this would be experimental evaluation, and we'll be working hard to make it as easy as possible (as discussed above).
from mlir-hlo.
Thanks @jpienaar and @burmako for keeping track of this new and exciting development. Stable interface (once stable :-) sounds like a good fit for this effort, I appreciate your careful evaluation on the matter.
from mlir-hlo.
@AlexandreEichenberger It took one week longer than initially expected, but the goals that were set in my previous comment have just been achieved. Earlier today we landed a bidirectional converter between StableHLO and MHLO: b9a0847, which concludes bootstrapping StableHLO as a software product.
At the moment, StableHLO includes all MHLO ops except the following 10 ops: AddDependencyOp
, AsyncDoneOp
, AsyncStartOp
, AsyncUpdateOp
, BitcastOp
, CopyOp
, DomainOp
, FusionOp
, PartitionIdOp
, XlaRngGetAndUpdateStateOp
. 9 of these ops aren't used by JAX, ONNX-MLIR, TensorFlow and Torch-MLIR, so we didn't include them in StableHLO. The 10th - CopyOp
- immediately folds into its operand, so we didn't include it either.
In a nutshell, StableHLO can now be used as a drop-in replacement for MHLO, with the added benefit of guaranteed backward and forward compatibIlity - see the RFC about this: openxla/stablehlo#115.
In the cases when MHLO is still needed, e.g. to run an MHLO pass or to lower to Linalg, it's just one hop away thanks to the StableHLO <=> MHLO conversions. We designed these conversions to be super robust (3.5k+ loc of exhaustive FileCheck tests + continuous integration that makes sure that these tests stay in sync with StableHLO and MHLO evolution), and we'll be maintaining them as part of MLIR-HLO moving forward.
I'll be talking about this at the OpenXLA community meeting tomorrow 9/20 at 8am PT (see invite), and I could give a presentation at one of the upcoming ONNX-MLIR meetings too. Please let us know what you think!
from mlir-hlo.
Related Issues (20)
- Missing CMake deps for THLO and suspect layering HOT 8
- ld.lld: error: unable to find library -lMLIRTosa HOT 2
- Deduplicate reduction subcomputations when converting from MHLO to HLO HOT 1
- pretty print chlo.comparison* HOT 3
- Failure to compile broadcast_in_dim HOT 4
- 'mhlo/IR/hlo_ops.h' file not found HOT 7
- when build mlir-hlo-opt, there is error that symbolic cannot find HOT 1
- [cmake build] MhloDialect target no longer carries correct binary include dir HOT 5
- Move CMake CI for this repo to be publicly visible
- Missing empty canonicalization for reduce
- Inclusive language (sanity -> safety) HOT 4
- Failed to import repo as a third party dependency using bazel HOT 2
- 32-bit erf is inaccurate for x > 1 HOT 8
- `erfinv(1.)` should be `inf` HOT 1
- Missing legalization for `mhlo.scatter` to standard MLIR
- `tiling_softmax.cc#tilePartialSoftmax: undefined reference to `mlir::gml_st::isSimpleBcastReduction' HOT 1
- Build & Test sections in readme are inacurate
- Missing CMake Dependency
- mhlo.dot inferred shape is incompatible with return type HOT 10
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mlir-hlo.