-
Notifications
You must be signed in to change notification settings - Fork 15.4k
[mlir][AMDGPU] Enable emulating vector buffer_atomic_fadd for bf16 on gfx942 #129029
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -189,6 +189,14 @@ void mlir::amdgpu::populateAmdgpuEmulateAtomicsPatterns( | |
| } else { | ||
| target.addIllegalOp<RawBufferAtomicFmaxOp>(); | ||
| } | ||
| // gfx950 has bf16 atomics | ||
| if (chipset < Chipset(9, 5, 0)) { | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. can you go based off the subtarget feature instead of isa versions. Really no code at all should ever be checking the isa version
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also is there something special about this emulation? Why can't you use the ordinary backend AtomicExpand handling?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This pass is for handling the MLIR ops that correspond to buffer intrinsics. (This pass is useful for code that doesn't/can't (ex. Triton setting cache modifiers) use buffer fat pointers). Also ... we don't have access to subtarget features
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
If you are producing IR you must have a system for managing subtarget features. ISA version checks are not acceptable
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This type of check is done in this cpp already (for Chipset(9, 0, 8)). I agree this is not the best way to handle this, but that seems like a refactor that could be done in a future PR?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. And re version checks not being acceptable, there's a bunch of them in the HIP headers (see https://github.com/ROCm/clr/blob/amd-staging/hipamd/include/hip/amd_detail/amd_hip_unsafe_atomics.h#L211 ) for example. The procedural history of this pass is that initially started as a way to implement the gfx941 workarounds for buffer intrinsics.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The example of the hip headers is a perfect demonstration of why this is a terrible idea you should not be emulating. Those headers are a superfund site that should be purged of all target specific implementation details, particularly of the listing isa version variety
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Unfortunately, I'm going to call for not letting the perfect be the enemy of the good here.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In terms of this patch, sure. But this system needs to be fixed
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
| target.addDynamicallyLegalOp<RawBufferAtomicFaddOp>( | ||
| [](RawBufferAtomicFaddOp op) -> bool { | ||
| Type elemType = getElementTypeOrSelf(op.getValue().getType()); | ||
| return !isa<BFloat16Type>(elemType); | ||
| }); | ||
| } | ||
| } | ||
| patterns.add< | ||
| RawBufferAtomicByCasPattern<RawBufferAtomicFaddOp, arith::AddFOp>, | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.