This is an archive of the discontinued LLVM Phabricator instance.

[mlir][vector] Rename vector reductions: `maxf` → `maximumf`, `minf` → `minimumf`
ClosedPublic

Authored by unterumarmung on Aug 23 2023, 7:26 AM.

Details

Summary

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.

Here, we are addressing task 2.1 from the plan, which involves renaming the vector reductions to align with the semantics of the corresponding LLVM intrinsics.

Diff Detail

Event Timeline

unterumarmung created this revision.Aug 23 2023, 7:26 AM
Herald added a reviewer: aartbik. · View Herald Transcript
Herald added a reviewer: ftynse. · View Herald Transcript
Herald added a reviewer: dcaballe. · View Herald Transcript
Herald added a reviewer: kuhar. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
unterumarmung requested review of this revision.Aug 23 2023, 7:26 AM
unterumarmung edited the summary of this revision. (Show Details)Aug 23 2023, 7:27 AM
unterumarmung edited the summary of this revision. (Show Details)
unterumarmung edited the summary of this revision. (Show Details)Aug 23 2023, 7:31 AM
mravishankar requested changes to this revision.Aug 23 2023, 8:57 AM

I think this is dependent on https://github.com/llvm/llvm-project/commit/dad9de0ae5360b18c890985d212bec266bf8c122. We've been carrying a revert of this commit for a while now cause it triggers an unsupported path in the CUDA backend for architectures earlier than Ampere. Would be too much to carry a chain of reverts. We should either make the lowering added in that commit opt-in/opt-out or wait for the issue in NVPTX backend to get fixed before moving forward here. I am sorry for delaying planned work, but this is having a downstream impact.

This revision now requires changes to proceed.Aug 23 2023, 8:57 AM

I think this is dependent on https://github.com/llvm/llvm-project/commit/dad9de0ae5360b18c890985d212bec266bf8c122. We've been carrying a revert of this commit for a while now cause it triggers an unsupported path in the CUDA backend for architectures earlier than Ampere. Would be too much to carry a chain of reverts. We should either make the lowering added in that commit opt-in/opt-out or wait for the issue in NVPTX backend to get fixed before moving forward here. I am sorry for delaying planned work, but this is having a downstream impact.

Hi there, @mravishankar!

Both @dcaballe and I completely understand your concerns. After discussing it, we've come to the decision not to revert the commit you mentioned upstream. Instead, we're going to push forward with the RFC as planned. Our main focus will be on tasks 2.1, 2.3, and 2.4, giving them the highest priority. This way, we can proceed with the commit in place and also address the NVPTX backend issue.

Regarding the patch, I want to highlight that I haven't completely removed support for minf and maxf. The reason behind this decision is that there are other operations reliant on the CombiningKind, and I'm being cautious not to inadvertently disrupt anything. That being said, I'm planning to easily reintroduce minf and maxf with the new semantics that have been present in LLVM for a longer duration. These intrinsics should be compatible with the older backends. To achieve this, I intend to implement both tasks 2.3 and 2.4 in the upcoming patch together.

Hope this clarifies the plan moving forward!

Just to provide a bit more context, we are trying to attack the NVPTX issue from two fronts: 1) @tra is looking into https://reviews.llvm.org/D158053 as a promising way to fix the issue quickly, 2) We are starting the min/max work from point 2.1 (and not 1.1) so that we can quickly introduce the minnum/maxnum variants that will provide an alternative lowering that is supported by NVPTX. Once those variants are in place, we can temporarily lower to them while the NVPTX issue is fixed, if that hasn't happened before. Does it sound reasonable?

tra added a comment.Aug 23 2023, 9:45 AM

@tra for visibility

BTW, NVPTX is not the only back-end which can't handle fminimum/fmaximum. Only some LLVM back-ends can currently lower fminimum/fmaximum IR instructions. Many just fail. E.g. ppc64: https://godbolt.org/z/8qb3Yxd9Y

https://reviews.llvm.org/D158238 should bring generic lowering for fminimum/fmaximum which can be used to provide fall-back implementation for the targets that don't support NaN-propagating min/max, but we'll likely need more changes to plumb it in on relevant targets (e.g. NVPTX for pre-sm80 GPUs).

It may be useful to provide some sort of escape hatch option to avoid generating fminimum/fmaximum, if this is intended to target platforms other than x86, aarch64,risc-v and nvptx.

I think this is dependent on https://github.com/llvm/llvm-project/commit/dad9de0ae5360b18c890985d212bec266bf8c122. We've been carrying a revert of this commit for a while now cause it triggers an unsupported path in the CUDA backend for architectures earlier than Ampere. Would be too much to carry a chain of reverts. We should either make the lowering added in that commit opt-in/opt-out or wait for the issue in NVPTX backend to get fixed before moving forward here. I am sorry for delaying planned work, but this is having a downstream impact.

Hi there, @mravishankar!

Both @dcaballe and I completely understand your concerns. After discussing it, we've come to the decision not to revert the commit you mentioned upstream. Instead, we're going to push forward with the RFC as planned. Our main focus will be on tasks 2.1, 2.3, and 2.4, giving them the highest priority. This way, we can proceed with the commit in place and also address the NVPTX backend issue.

Regarding the patch, I want to highlight that I haven't completely removed support for minf and maxf. The reason behind this decision is that there are other operations reliant on the CombiningKind, and I'm being cautious not to inadvertently disrupt anything. That being said, I'm planning to easily reintroduce minf and maxf with the new semantics that have been present in LLVM for a longer duration. These intrinsics should be compatible with the older backends. To achieve this, I intend to implement both tasks 2.3 and 2.4 in the upcoming patch together.

Hope this clarifies the plan moving forward!

Well, that doesnt address currently broken users downstream. Looks like the issue is not limited to NVPTX backend alone. Given that there are several end-to-end flows where these are used there needs to be a way to opt out of these transformations till all the backends can handle this lowering. As it stands I dont see an easy way to do it, and that should be a blocker moving forward. Please provide some guidance for what downstream users should do to avoid hitting compilation errors with this change.

Please provide some guidance for what downstream users should do to avoid hitting compilation errors with this change.

When 2.3 and 2.4 points are implemented, we'll be able to temporarily lower to the non-NaN propagating minnum/maxnum variants for those backends without support for the NaN propagating ones.
Perhaps we can wait to land this patch until 2.3 and 2.4 are implemented and land everything in one shot.

Add default clause to the switch MaskedReductionOpConversion because there is no masked intrinsics for maximumf/minumumf vector reductions that match the needed semantics

dcaballe added inline comments.Aug 23 2023, 4:28 PM
mlir/lib/Conversion/VectorToLLVM/ConvertVectorToLLVM.cpp
899

We also need a workaround for this before landing or https://github.com/llvm/llvm-project/issues/64940 to be fixed. Masked reductions are common to be generate. We could generate a vector select that sets the masked-out elements of the input to the identity value, and then use the unmasked version of the intrinsics.

unterumarmung added inline comments.Aug 24 2023, 1:33 AM
mlir/lib/Conversion/VectorToLLVM/ConvertVectorToLLVM.cpp
899

I agree.
I suggest to implement it in a separate patch, so we do not overcomplicate this one, and then merge all 3 patches at the same time.
I'll look into creating the workaround with the unmasked intrinsic and selecting the needed values. Could you please share a pseudocode of the possible lowering or some existing examples from the codebase? I'd help out a lot. Thanks.

unterumarmung added inline comments.Aug 24 2023, 1:38 AM
mlir/lib/Conversion/VectorToLLVM/ConvertVectorToLLVM.cpp
899

It'd*

unterumarmung edited the summary of this revision. (Show Details)Aug 25 2023, 10:45 AM

@mravishankar @dcaballe Could you please re-review the PR?

@mravishankar @dcaballe Could you please re-review the PR?

Could one of you give me a stack of patches I could cherry-pick to make sure we can drop the revert we've been carrying. I dont have any material concern here, but I am trying to not have a sequence of reverts/partial reverts to carry downstream.... If there are a stack of patches that can make the revert go away, I am happy with these changes.

@mravishankar @dcaballe Could you please re-review the PR?

Could one of you give me a stack of patches I could cherry-pick to make sure we can drop the revert we've been carrying. I dont have any material concern here, but I am trying to not have a sequence of reverts/partial reverts to carry downstream.... If there are a stack of patches that can make the revert go away, I am happy with these changes.

I'm sorry for the delay
Here is the stack with all the three patches: https://github.com/unterumarmung/llvm-project/commits/vector-reduction-changes
I've rebased it to the current main and run tests locally - seems fine

@mravishankar @dcaballe Could you please re-review the PR?

Could one of you give me a stack of patches I could cherry-pick to make sure we can drop the revert we've been carrying. I dont have any material concern here, but I am trying to not have a sequence of reverts/partial reverts to carry downstream.... If there are a stack of patches that can make the revert go away, I am happy with these changes.

I'm sorry for the delay
Here is the stack with all the three patches: https://github.com/unterumarmung/llvm-project/commits/vector-reduction-changes
I've rebased it to the current main and run tests locally - seems fine

Thanks! I created a draft PR in IREE (downstream) here https://github.com/openxla/iree/pull/14888 with the top three commits of that branch. If everything passes, then feel free to land this change (I am going to be out on vacation soon, so please co-ordinate with @dcaballe ).

dcaballe accepted this revision.Sep 13 2023, 3:13 PM
This revision was not accepted when it landed; it landed in state Needs Review.Sep 13 2023, 3:50 PM
This revision was automatically updated to reflect the committed changes.