tvm-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aca88 via TVM Discuss <nore...@discuss.tvm.ai>
Subject [TVM Discuss] [Development] Google lasted work: MLIR Primer
Date Thu, 04 Apr 2019 10:09:37 GMT


[quote="tqchen, post:2, topic:1721"]
MLIR as itself is a meta-way of defining IRs, in the folks’ word “XML for IRs” ... Concrete
compiler solutions still need to be built for each layer of the dialect languages, and they
can be very different due to the difference in the semantics of the operators.
[/quote]

So correct me if I am wrong at interpreting your view:
MLIR would be the abstract class of IRs, and IRs at different scopes (i.e. the scope of TVM
IR is at a higher level than LLVM IR) would be derived classes of it. In these derived classes
(MLIR dialects) the MLIR methods are overloaded (and extended) for specifics of the derived
classes. Therefore TVM IR passes are these overloaded methods and we dont have to worry that
MLIR will make TVM obsolete?

A couple of things which still kind of bugs me with this interpretation are:
1. MLIR seems to (natively?) support descriptions targeted for polyhedral dialects. Since
TVM does not use the polyhedral model, I guess we would be limited in the usage of this information
but could it also be an impairment? 
2. If MLIR is the "root class" of all other dialects, then if a parser reads the highest level
input form (ex. ONNX) and translates it into MLIR, how can we ensure that the parser doesnt
omit any information which we need in the TVM dialect?





---
[Visit Topic](https://discuss.tvm.ai/t/google-lasted-work-mlir-primer/1721/14) to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/79f528aa7e515ec11585670dc434dc73370cf86b45297b42838259e2b137f761).

Tianqi Chen, UW, Seattle, WA, 98105, United States
http://tracking.discuss.tvm.ai/tracking/unsubscribe?msgid=bLwWY4h8tuQ8Lqt2DFNA5w2
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message