[SPIRV] Fix crash due to incorrect state of the SPIRVGlobalRegistry.
Also, simplified checks in test that were not stricly necessary and were failing with this fix.
--Added support for the extension SPV_KHR_non_semantic_info
--Added support for the extension SPV_KHR_relaxed_extended_instruction
--Added instructions from the documentation of the extension.
--Added supporting tests for the same.
[RISCV] Ensure false dominates in vmerge peephole (#181664)
When folding vmerge into it's true operand, true will eventually use the
false operand as its passthru, but we don't check that the instruction
defining false dominates true. This can cause a use before def.
Fix this by sinking true past false. We already do this for the mask, so
this does it in the same call to ensureDominates.
We don't seem to run into this with current codegen but upcoming changes
to RISCVVLOptimizer expose it.
[ValueTracking] Treat fmul NaN sign bit as unknown to prevent incorrect fabs folding (#180339)
### Summary
ValueTracking currently allows InstSimplify to reason about the sign bit
of an `fmul` result based on the sign information of its operands. This
can lead to removing a subsequent `llvm.fabs` under the assumption that
the multiplication result is already non-negative.
However, `fmul` may produce NaNs whose sign bit is non-deterministic.
Since `llvm.fabs` canonicalizes the sign bit of NaNs, eliminating
llvm.fabs` in these cases can change observable behaviour.
### Change
Update ValueTracking to treat the sign bit of `fmul` as unknown when
NaNs are possible, preventing InstSimplify from incorrectly removing
llvm.fabs ` after `fmul`.
Fixes #179613
[VPlan] Plumb recurrence FMFs through VPReductionPHIRecipe via VPIRFlags. NFC (#181694)
In order to be able to create selects for reduction phis through tail
folding in foldTailByMasking (#176143), make VPReductionPHIRecipe an
instance of VPIRFlags and plumb the FMFs from the original RdxDesc.
This allows us to remove more uses of the RecurrenceDescriptor in
addReductionResultComputation, which should help untie it from
LoopVectorizationLegality.
[AArch64] Fix codegen for histograms with i64 increments (#181808)
Histograms don't do any legalisation on the loaded data type, so if the
'add' would need to be performed on a vector of i64's, then we can't use
the more optimal addressing with i32 offsets as that would return a
vector of nxv4i32 which wouldn't get widened.
This fixes https://github.com/llvm/llvm-project/issues/181764
[mlir][shard] Empowering resharding (#180962)
Enabling many more resharding cases by dealing with dimension by dimension,
try-applying various patterns on a single dimension.
