merge main into amd-staging #723
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add test cases for upcoming argmin vectorization changes that have wrapping IV ranges.
The canonical IV is always a single scalar. They are already treated as uniform-across-UF-and-VF. This should currently be NFC.
... as they are closely related. Also improve the comments.
…igned zero (llvm#112852)" (llvm#168838) This reverts commit 363b059. This is a follow up of llvm#166912. Sorry for not noticing the change at the beginning, but I disagree with both sNaN and signed zero semantics change. I have 3 justifications: - llvm.minnum and llvm.maxnum are common intrinsics, we cannot change the definition just because "some architectures" support the changed semantic. For example, X86 min/max instructions neither distinguish sNaN nor signed zero. We have to add couples of extra instructions to match with the new definition, which makes the intrinsics less efficient. But efficient is not the reason for the objection. I object because such cost is unnecessary; - As the example ``minnum(fadd(sNaN, -0.0), 1.0)`` shows, minnum/maxnum themself cannot guarantee consistent result if multiple FP arithmetic operations involved. It makes the sacrifice of performance totally unnecessary. `Behavior of Floating-Point NaN values` notes all NaNs can be treated as quiet NaNs unless using Constrained Floating-Point Intrinsics. So the cost is only worth for constrained minnum/maxnum ones if we want to define them; - Signed zero handling is unnecessary either, because even the C functions don't require it. If any other front ends require, they can use the existing fminnum_ieee/fmaxnum_ieee or define new intrinsics; Fixes: llvm#138303 and llvm#169122
… coalesceLoops function (llvm#169514) Fix llvm#169483 by using iter argument replace init when delete loop in the coalesceLoops function.
…169299) ### Summary This patch let RISCVTargetLowering::lowerSELECT to lower some floating-point select operations through an integer zicond select when: * Zicond is available, and * FP values live in GPRs (Zfinx/Zdinx), and * Select condition is an integer type. In that scenario there is no extra cost for GPR <-> "FP GPR" moves, so we can implement FP selects with a CZERO-based sequence instead of a branch. For example, for ```c float foo(int cond, float x) { return (cond != 0) ? x : 0.0f; } ``` the current lowering produces: ```asm foo: mv a2, a0 li a0, 0 beqz a2, .LBB0_2 .LBB0_1: mv a0, a1 .LBB0_2: ret ``` With this patch, when targeting rv64ima_zicond_zfinx we instead get: ```asm foo: czero.nez a2, zero, a0 czero.eqz a0, a1, a0 or a0, a2, a0 ret ``` The existing branch-based lowering is preserved for: * targets without Zicond * targets where FP registers are separate (+f, +d without zfinx/zdinx) ### Testing Adds llvm/test/CodeGen/RISCV/zicond-fp-select-zfinx.ll to cover: * RV64 Zfinx/Zicond vs Zfinx without Zicond * RV64 Zdinx/Zicond vs Zdinx without Zicond * RV32 Zfinx/Zicond vs Zfinx without Zicond Also adds baseline RV32F/RV64F/RV64D cases to ensure we still use branches when FP registers are separate. The tests check that: * With Zicond + Zfinx/Zdinx, FP select lowers to a CZERO+OR sequence with no conditional branches. * Without Zicond (or without Zfinx/Zdinx), we still get branch-based code and no czero.* instructions.
…xed_point and name change of SPV_INTEL_arbitrary_precision_integers to SPV_ALTERA_arbitrary_precision_integers (llvm#136085) --Added support for extension SPV_ALTERA_arbitrary_precision_fixed_point --Added test files for extension SPV_ALTERA_arbitrary_precision_fixed_point
…aN and signed zero (llvm#112852)"" (llvm#170067) Reverts llvm#168838 Justification is confused and this did not receive adequate discussion, particularly during a holiday week
llvm#169823) During operation legalization, element type should have been turn into XLenVT which makes the SHL a no-op. We need to use exact vector element type instead.
ronlieb
approved these changes
Dec 1, 2025
ronlieb
requested review from
a team
and removed request for
antiagainst and
kuhar
Collaborator
Author
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.