| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[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 | 4 年前 | |
[mlir] Make the ml_program dialect allow all of its operations to be inlined. (#85479) | 2 年前 | |
[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 helper functions but decided against adding an abstraction there early given size of duplication and creating accidental coupling. Differential Revision: https://reviews.llvm.org/D127813 | 4 年前 | |
[mlir][MLProgram] Add MLProgram to MemRef bufferization pass (#75103) There is currently no lowering out of ml_program in the LLVM repository. This change adds a lowering to memref so that it can be lowered all the way to LLVM. This lowering was taken from the [reference backend in torch-mlir](https://github.com/llvm/torch-mlir/commit/f41695360019bde71d52ca7548944d5488779e12 ). I had tried implementing the BufferizableOpInterface for ml_program instead of adding a new pass but that did not work because OneShotBufferize does not visit module-level ops like ml_program.global. | 2 年前 | |
[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 helper functions but decided against adding an abstraction there early given size of duplication and creating accidental coupling. Differential Revision: https://reviews.llvm.org/D127813 | 4 年前 | |
[mlir][mlprogram] Add mlprogram-pipeline-globals optimization pass Added pass optimizes MLProgram global operations by reducing to only the minimal load/store operations for global tensors. This avoids unnecessary global operations throughout a program and potentially improves operation gusion. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D159228 | 2 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 4 年前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 2 年前 |