Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-01-16T12:55:05+00:00 2020-01-16T12:55:05+00:00 Benjamin Kramer benny.kra@googlemail.com 2020-01-15T16:51:51+00:00 urn:sha1:ac446302ca4145cdc89f377c0c364c29ee303be5 This reverts commit 4624a1e8ac8a3f69cc887403b976f538f587744a. Causing problems downstream. (cherry picked from commit 0133cc60e4e230ee2c176c23eff5aa2f4ee17a75) 2020-01-14T11:05:47+00:00 Tres Popp tpopp@google.com 2020-01-14T10:09:59+00:00 urn:sha1:4624a1e8ac8a3f69cc887403b976f538f587744a Summary: This is based on the use of code constantly checking for an attribute on a model and instead represents the distinct operaion with a different op. Instead, this op can be used to provide better filtering. Reviewers: herhut, mravishankar, antiagainst, rriddle Reviewed By: herhut, antiagainst, rriddle Subscribers: liufengdb, aartbik, jholewinski, mgorny, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, csigg, arpith-jacob, mgester, lucyrfox, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72336 2020-01-11T16:54:39+00:00 River Riddle riverriddle@google.com 2020-01-11T16:54:04+00:00 urn:sha1:2bdf33cc4c733342fc83081bc7410ac5e9a24f55 Summary: These were temporary methods used to simplify the transition. Reviewed By: antiagainst Differential Revision: https://reviews.llvm.org/D72548 2020-01-09T09:06:00+00:00 Alex Zinenko zinenko@google.com 2020-01-07T19:00:54+00:00 urn:sha1:08778d8c4fd8a6519c7f27bfa6b09c47262cb844 Introduce a set of function that promote a memref argument of a `gpu.func` to workgroup memory using memory attribution. The promotion boils down to additional loops performing the copy from the original argument to the attributed memory in the beginning of the function, and back at the end of the function using all available threads. The loop bounds are specified so as to adapt to any size of the workgroup. These utilities are intended to compose with other existing utilities (loop coalescing and tiling) in cases where the distribution of work across threads is uneven, e.g. copying a 2D memref with only the threads along the "x" dimension. Similarly, specialization of the kernel to specific launch sizes should be implemented as a separate pass combining constant propagation and canonicalization. Introduce a simple attribute-driven pass to test the promotion transformation since we don't have a heuristic at the moment. Differential revision: https://reviews.llvm.org/D71904 2019-12-24T00:36:53+00:00 River Riddle riverriddle@google.com 2019-12-23T22:45:01+00:00 urn:sha1:e62a69561fb9d7b1013d2853da68d79a7907fead ValuePtr was a temporary typedef during the transition to a value-typed Value. PiperOrigin-RevId: 286945714 2019-12-23T23:33:37+00:00 Mehdi Amini aminim@google.com 2019-12-23T17:35:36+00:00 urn:sha1:56222a0694e4caf35e892d70591417c39fef1185 PiperOrigin-RevId: 286906740 2019-12-23T06:00:23+00:00 River Riddle riverriddle@google.com 2019-12-23T05:59:55+00:00 urn:sha1:35807bc4c5c9d8abc31ba0b2f955a82abf276e12 This is an initial step to refactoring the representation of OpResult as proposed in: https://groups.google.com/a/tensorflow.org/g/mlir/c/XXzzKhqqF_0/m/v6bKb08WCgAJ This change will make it much simpler to incrementally transition all of the existing code to use value-typed semantics. PiperOrigin-RevId: 286844725 2019-12-18T17:29:20+00:00 River Riddle riverriddle@google.com 2019-12-18T17:28:48+00:00 urn:sha1:4562e389a43caa2e30ebf277c12743edafe6a0ac Aside from being cleaner, this also makes the codebase more consistent. PiperOrigin-RevId: 286206974 2019-12-16T20:12:48+00:00 Alex Zinenko zinenko@google.com 2019-12-16T20:12:20+00:00 urn:sha1:6273fa0c6a85985395993e74c92a17709311fb84 This updates the lowering pipelines from the GPU dialect to lower-level dialects (NVVM, SPIRV) to use the recently introduced gpu.func operation instead of a standard function annotated with an attribute. In particular, the kernel outlining is updated to produce gpu.func instead of std.func and the individual conversions are updated to consume gpu.funcs and disallow standard funcs after legalization, if necessary. The attribute "gpu.kernel" is preserved in the generic syntax, but can also be used with the custom syntax on gpu.funcs. The special kind of function for GPU allows one to use additional features such as memory attribution. PiperOrigin-RevId: 285822272 2019-12-07T18:35:41+00:00 River Riddle riverriddle@google.com 2019-12-07T18:35:01+00:00 urn:sha1:d6ee6a031063cb99ca9828f1698a60536ffbb38a This allows for users to provide operand_range and result_range in builder.create<> calls, instead of requiring an explicit copy into a separate data structure like SmallVector/std::vector. PiperOrigin-RevId: 284360710