-
Notifications
You must be signed in to change notification settings - Fork 580
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: MLIR Dialects for TensorFlow #115
Conversation
@joker-eph thanks for the RFC. I note it doesn't have the end of a review period annotated on it. Usually this would be two weeks, ie. 6/27. Are you good with that? If so, I'll add in. |
@ewilderj That sounds fine yes. |
@byronyi The collective ops don't (as far as I know) require any special treatment by the executor, so I think they're handled by the TensorFlow dialect. |
@joker-eph was this RFC accepted by review? If so can you copy any notes from the review meeting here? Then I'll be able to merge it. |
@ewilderj can you add your review so this can be merged? |
Change status to Accepted
This proposal is open for review until 2019-06-27
TensorFlow MLIR Dialects
Objective
MLIR is the intermediate representation and compiler framework we are investing in to build the compiler infrastructure for TensorFlow. The representation for TensorFlow exposed in this document will be what future high-level transformations will operate on.
We make use of two different dialects to model TensorFlow graphs in MLIR: first the tf_executor dialect that represents the execution model of the TensorFlow executor (e.g. control dependencies, deadness propagation) and the tf dialect which represent the regular operations in a TensorFlow graph (the ones that don’t have special contract with the executor).
One intent of this design is that TensorFlow 2.x features can choose to target just the tf dialect, allowing us to phase out the tf_executor dialect in subsequent TensorFlow releases. The combination of the two dialects allows to represent arbitrary existing TensorFlow graphs.
The representation in this document does not address the specific needs of accelerators or "custom backends" for TensorFlow. We plan to provide a generic infrastructure for replacing the TF/XLA bridge with a more flexible and reusable system across targets. A later design proposal will address these aspects. Also this representation does not address shape inference, an independent design exploration is being conducted separately at the moment.