llvm-project.git/mlir/lib/Dialect/AMDGPU/Transforms/EmulateAtomics.cpp, branch main Unnamed repository; edit this file 'description' to name the repository. [mlir][NFC] update `mlir/Dialect` create APIs (14/n) (#149920) 2025-07-24T18:03:47+00:00 Maksim Levental maksim.levental@gmail.com 2025-07-24T18:03:47+00:00 967626b842551ecd997c0d10eb68c3015b63a3d7 See https://github.com/llvm/llvm-project/pull/147168 for more info. 
See https://github.com/llvm/llvm-project/pull/147168 for more info.
 [mlir] Remove unused includes (NFC) (#148535) 2025-07-13T20:13:01+00:00 Kazu Hirata kazu@google.com 2025-07-13T20:13:01+00:00 cac806bcc5b3367ca7573c2c5ae590379d89b84f 






[mlir][amdgpu][nfc] Add PatternBenefit to populate methods (#144663)
2025-06-18T13:19:17+00:00

Kunwar Grover
groverkss@gmail.com

2025-06-18T13:19:17+00:00

6729da647afa2b0ee040ccd4f06153e45d6ca738












[mlir][AMDGPU] Enable emulating vector buffer_atomic_fadd for bf16 on gfx942 (#129029)
2025-03-13T19:30:45+00:00

Daniel Hernandez-Juarez
dhernandez0@gmail.com

2025-03-13T19:30:45+00:00

64f67f870d6eb866bef6b49a8388915c73db40bc

- Change to make sure architectures < gfx950 emulate bf16
buffer_atomic_fadd
- Add tests for bf16 buffer_atomic_fadd and architectures: gfx12, gfx942
and gfx950

---------

Co-authored-by: Jakub Kuderski <kubakuderski@gmail.com>




- Change to make sure architectures < gfx950 emulate bf16
buffer_atomic_fadd
- Add tests for bf16 buffer_atomic_fadd and architectures: gfx12, gfx942
and gfx950

---------

Co-authored-by: Jakub Kuderski <kubakuderski@gmail.com>






[AMDGPU][MLIR] Replace gfx940 and gfx941 with gfx942 in MLIR (#125836)
2025-02-19T09:05:45+00:00

Fabian Ritter
fabian.ritter@amd.com

2025-02-19T09:05:45+00:00

8900e412aec04b202b9f071d110f96546989beef

gfx940 and gfx941 are no longer supported. This is one of a series of
PRs to remove them from the code base.

For SWDEV-512631




gfx940 and gfx941 are no longer supported. This is one of a series of
PRs to remove them from the code base.

For SWDEV-512631






[mlir][AMDGPU] Enable emulating vector buffer_atomic_fadd on gfx11 (#108312)
2024-09-12T14:47:52+00:00

Krzysztof Drewniak
Krzysztof.Drewniak@amd.com

2024-09-12T14:47:52+00:00

9596e83b2aa9017f4ebec3c150ca3aadd047762b

* Fix a bug introduced by the Chipset refactoring in #107720 where
atomics emulation for adds was mistakenly applied to gfx11+
* Add the case needed for gfx11+ atomic emulation, namely that gfx11
doesn't support atomically adding a v2f16 or v2bf16, thus requiring
MLIR-level legalization for buffer intrinsics that attempt to do such an
addition
* Add tests, including tests for gfx11 atomic emulation

Co-authored-by: Manupa Karunaratne <manupa.karunaratne@amd.com>




* Fix a bug introduced by the Chipset refactoring in #107720 where
atomics emulation for adds was mistakenly applied to gfx11+
* Add the case needed for gfx11+ atomic emulation, namely that gfx11
doesn't support atomically adding a v2f16 or v2bf16, thus requiring
MLIR-level legalization for buffer intrinsics that attempt to do such an
addition
* Add tests, including tests for gfx11 atomic emulation

Co-authored-by: Manupa Karunaratne <manupa.karunaratne@amd.com>






[mlir][amdgpu] Align Chipset with TargetParser (#107720)
2024-09-09T15:12:26+00:00

Jakub Kuderski
jakub@nod-labs.com

2024-09-09T15:12:26+00:00

763bc9249cf0b7da421182e24716d9a569fb5184

Update the Chipset struct to follow the `IsaVersion` definition from
llvm's `TargetParser`. This is a follow up to
https://github.com/llvm/llvm-project/pull/106169#discussion_r1733955012.

* Add the stepping version. Note: This may break downstream code that
compares against the minor version directly.
* Use comparisons with full Chipset version where possible.

Note that we can't use the code in `TargetParser` directly because the
chipset utility is outside of `mlir/Target` that re-exports llvm's
target library.




Update the Chipset struct to follow the `IsaVersion` definition from
llvm's `TargetParser`. This is a follow up to
https://github.com/llvm/llvm-project/pull/106169#discussion_r1733955012.

* Add the stepping version. Note: This may break downstream code that
compares against the minor version directly.
* Use comparisons with full Chipset version where possible.

Note that we can't use the code in `TargetParser` directly because the
chipset utility is outside of `mlir/Target` that re-exports llvm's
target library.






[mlir][AMDGPU] Add gfx941 to buffer atomics emulation
2023-09-13T16:07:07+00:00

Krzysztof Drewniak
Krzysztof.Drewniak@amd.com

2023-05-18T20:13:44+00:00

ba6d7a0f25f335a3106d2949dda18a15ac188792

Reviewed By: fmorac

Differential Revision: https://reviews.llvm.org/D152299





Reviewed By: fmorac

Differential Revision: https://reviews.llvm.org/D152299







[mlir][arith] Rename operations: `maxf` → `maximumf`, `minf` → `minimumf` (#65800)
2023-09-12T05:02:19+00:00

Daniil Dudkin
39276703+unterumarmung@users.noreply.github.com

2023-09-12T05:02:19+00:00

8a6e54c9b3080f1b8e1a925bf1a39730223b99f9

This patch is part of a larger initiative aimed at fixing floating-point `max` and `min` operations in MLIR: https://discourse.llvm.org/t/rfc-fix-floating-point-max-and-min-operations-in-mlir/72671.

This commit addresses Task 1.2 of the mentioned RFC. By renaming these operations, we align their names with LLVM intrinsics that have corresponding semantics.




This patch is part of a larger initiative aimed at fixing floating-point `max` and `min` operations in MLIR: https://discourse.llvm.org/t/rfc-fix-floating-point-max-and-min-operations-in-mlir/72671.

This commit addresses Task 1.2 of the mentioned RFC. By renaming these operations, we align their names with LLVM intrinsics that have corresponding semantics.






Finish renaming getOperandSegmentSizeAttr() from `operand_segment_sizes` to `operandSegmentSizes`
2023-08-10T02:37:01+00:00

Mehdi Amini
joker.eph@gmail.com

2023-08-09T19:47:13+00:00

363b655920c49a4bcb0869f820ed40aac834eebd

This renaming started with the native ODS support for properties, this is completing it.

A mass automated textual rename seems safe for most codebases.
Drop also the ods prefix to keep the accessors the same as they were before
this change:
 properties.odsOperandSegmentSizes
reverts back to:
 properties.operandSegementSizes

The ODS prefix was creating divergence between all the places and make it harder to
be consistent.

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D157173





This renaming started with the native ODS support for properties, this is completing it.

A mass automated textual rename seems safe for most codebases.
Drop also the ods prefix to keep the accessors the same as they were before
this change:
 properties.odsOperandSegmentSizes
reverts back to:
 properties.operandSegementSizes

The ODS prefix was creating divergence between all the places and make it harder to
be consistent.

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D157173