| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir][GPU] Rename MLIRGPUOps CMake target to MLIRGPUDialect This is for consistency with other dialects. Differential Revision: https://reviews.llvm.org/D150659 | 3 年前 | |
[mlir][gpu] Move GPU headers into IR/ and Transforms/ Depends on D127350 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D127352 | 4 年前 | |
[mlir][GPU] Improve handling of GPU bounds (#95166) This change reworks how range information for GPU dispatch IDs (block IDs, thread IDs, and so on) is handled. 1. known_block_size and known_grid_size become inherent attributes of GPU functions. This makes them less clunky to work with. As a consequence, the gpu.func lowering patterns now only look at the inherent attributes when setting target-specific attributes on the llvm.func that they lower to. 2. At the same time, gpu.known_block_size and gpu.known_grid_size are made official dialect-level discardable attributes which can be placed on arbitrary functions. This allows for progressive lowerings (without this, a lowering for gpu.thread_id couldn't know about the bounds if it had already been moved from a gpu.func to an llvm.func) and allows for range information to be provided even when gpu.*_{id,dim} are being used outside of a gpu.func context. 3. All of these index operations have gained an optional upper_bound attribute, allowing for an alternate mode of operation where the bounds are specified locally and not inherited from the operation's context. These also allow handling of cases where the precise launch sizes aren't known, but can be bounded more precisely than the maximum of what any platform's API allows. (I'd like to thank @benvanik for pointing out that this could be useful.) When inferring bounds (either for range inference or for setting range during lowering) these sources of information are consulted in order of specificity (upper_bound > inherent attribute > discardable attribute, except that dimension sizes check for known_*_bounds to see if they can be constant-folded before checking their upper_bound). This patch also updates the documentation about the bounds and inference behavior to clarify what these attributes do when set and the consequences of setting them up incorrectly. --------- Co-authored-by: Mehdi Amini <joker.eph@gmail.com> | 2 年前 | |
[mlir] Use StringRef::operator== instead of StringRef::equals (NFC) (#91560) I'm planning to remove StringRef::equals in favor of StringRef::operator==. - StringRef::operator==/!= outnumber StringRef::equals by a factor of 10 under mlir/ in terms of their usage. - The elimination of StringRef::equals brings StringRef closer to std::string_view, which has operator== but not equals. - S == "foo" is more readable than S.equals("foo"), especially for !Long.Expression.equals("str") vs Long.Expression != "str". | 2 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 2 年前 |