[mlir] Split MLProgram global load and store to Graph variants* Split ops into X_graph variants as discussed;* Remove tokens from non-Graph region variants and rely on side-effect modelling ther
[mlir] Split MLProgram global load and store to Graph variants* Split ops into X_graph variants as discussed;* Remove tokens from non-Graph region variants and rely on side-effect modelling there while removing side-effect modelling from Graph variants and relying on explicit ordering there;* Make tokens required to be produced by Graph variants - but kept explicit token type specification given previous discussion on this potentially being configurable in future;This results in duplicating some code. I considered adding helperfunctions but decided against adding an abstraction there early givensize of duplication and creating accidental coupling.Differential Revision: https://reviews.llvm.org/D127813
show more ...
[mlir] (NFC) Clean up bazel and CMake target namesAll dialect targets in bazel have been named *Dialect and all dialecttargets in CMake have been named MLIR*Dialect.
[mlir] Add global_load and global_store ops to ml_program.* Adds simple, non-atomic, non-volatile, non-synchronized direct load/store ops.Differential Revision: https://reviews.llvm.org/D126230
[mlir] Add GlobalOp, GlobalLoadConstOp to ml_program.The approach I took was to define a dialect 'extern' attribute that a GlobalOp can take as a value to signify external linkage. I think this app
[mlir] Add GlobalOp, GlobalLoadConstOp to ml_program.The approach I took was to define a dialect 'extern' attribute that a GlobalOp can take as a value to signify external linkage. I think this approach should compose well and should also work with wherever the OpaqueElements work goes in the future (since that is just another kind of attribute). I special cased the GlobalOp parser/printer for this case because it is significantly easier on the eyes.In the discussion, Jeff Niu had proposed an alternative syntax for GlobalOp that I ended up not taking. I did try to implement it but a) I don't think it made anything easier to read in the common case, and b) it made the parsing/printing logic a lot more complicated (I think I would need a completely custom parser/printer to do it well). Please have a look at the common cases where the global type and initial value type match: I don't think how I have it is too bad. The less common cases seem ok to me.I chose to only implement the direct, constant load op since that is non side effecting and there was still discussion pending on that.Differential Revision: https://reviews.llvm.org/D124318
[mlir] Introduce ml_program dialect.Differential Revision: https://reviews.llvm.org/D120203