[InstCombine][X86] simplifyX86FPMaxMin - allow NegZero for single operand

[RKSimon]

Follow up to #173270 and #175162

In cases where both operands are +/- 0.0f, SSE max/min instructions always return the second operand, meaning we can slightly relax the fpclass forbidden masks on a per-operand basis:

• for converting to maxnum cases we only forbid -0.0f (fcNegZero) in the second operand
• for converting to minnum cases we only forbid -0.0f (fcNegZero) in the first operand

CC @phoebewang in case I've missed something

[llvmbot]

@llvm/issue-subscribers-backend-x86

Author: Simon Pilgrim (RKSimon)

Details

Follow up to #173270 and #175162

In cases where both operands are +/- 0.0f, SSE max/min instructions always return the second operand, meaning we can slightly relax the fpclass forbidden masks on a per-operand basis:

• for converting to maxnum cases we only forbid -0.0f (fcNegZero) in the second operand
• for converting to minnum cases we only forbid -0.0f (fcNegZero) in the first operand

CC @phoebewang in case I've missed something

[llvmbot]

Hi!

This issue may be a good introductory issue for people new to working on LLVM. If you would like to work on this issue, your first steps are:

1. Check that no other contributor is working on this issue. If someone is assigned to the issue or claimed to be working on it, ping the person. After one week without a response, the assignee may be changed.
2. Leave a comment indicating that you are working on the issue, or just create a pull request after following the steps below. Mention this issue in the description of the pull request.
3. Fix the issue locally.
4. Run the test suite locally. Remember that the subdirectories under test/ create fine-grained testing targets, so you can e.g. use make check-clang-ast to only run Clang's AST tests.
5. Create a Git commit.
6. Run git clang-format HEAD~1 to format your changes.
7. Open a pull request to the upstream repository on GitHub. Detailed instructions can be found in GitHub's documentation. Mention this issue in the description of the pull request.

If you have any further questions about this issue, don't hesitate to ask via a comment in the thread below.

[llvmbot]

@llvm/issue-subscribers-good-first-issue

Author: Simon Pilgrim (RKSimon)

Details

Follow up to #173270 and #175162

In cases where both operands are +/- 0.0f, SSE max/min instructions always return the second operand, meaning we can slightly relax the fpclass forbidden masks on a per-operand basis:

• for converting to maxnum cases we only forbid -0.0f (fcNegZero) in the second operand
• for converting to minnum cases we only forbid -0.0f (fcNegZero) in the first operand

CC @phoebewang in case I've missed something

[phoebewang]

For now, we don't consider signed 0 in minnum/maxnum lowering. So it's purely rely on no middle optimizations swap the operand. But I saw report that vectorizer may swap the operand.

[RKSimon]

Yes, commutation can be a problem. The idea for this ticket came up when I was thinking about #170069 - DAG fpclass isn't as great as ValueTracking yet, but we could attempt to detect if -0.0f never occurs on either operand which might allow better lowering to X86ISD FMAX/FMIN. The reason I'm so keen on converting to generic max/min in the middle end is to make it easier to do more re-vectorisation in the middle-end and not keep dumping it in the backend.

[ItsGunjit]

Could you assign me this issue?

[MadhurKumar004]

@ItsGunjit are you still working on this?