yongwww edited a comment on pull request #7060: URL: https://github.com/apache/tvm/pull/7060#issuecomment-741706021
@tqchen Thanks for the comment. We chose to go with MLIR/HLO instead of XLA HLO, because HLO operations works on tensors with static shape (dynamic ops like [NMS](https://github.com/tensorflow/tensorflow/issues/42879) are not supported by XLA HLO), this limits op/model coverage. MLIR/HLO is possible to represent dynamism, for example, the mhlo lowered from MLIR/TensorFlow. Introducing Relay Dialect does bring some extra effort for adding relay operators, and translation from MLIR/HLO to Relay is pretty similar to translation from MLIR/Relay to Relay. Considering several dialects are defined already, like [MLIR/TensorFlow](https://github.com/tensorflow/tensorflow/tree/master/tensorflow/compiler/mlir/tensorflow/ir) (NMS is in it now), [MLIR/TFLite](https://github.com/tensorflow/tensorflow/tree/master/tensorflow/compiler/mlir/lite), [MLIR/HLO](https://github.com/tensorflow/mlir-hlo), [MLIR/ONNX](https://github.com/onnx/onnx-mlir/), etc. Having Relay Dialect will make the conversion from other potential MLIR Dialects to Relay(via mlir/relay) easy, writing some mlir passes/patterns will make the conversion between dialects happen under MLIR conversion infra. Besides, folks might translate relay to mlir/relay even though personally I don't think we need do this. If we believe/bet there are translations from other mlir dialects to relay in the future, I think having relay dialect is not a bad thing. I am okay to go with mlir/hlo to relay directly. Please let me know what you guys think. cc: @yangjunpro @jroesch @yidawang ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
