[mlir][CSE] Fix double-counting of numCSE statistic (#189802)
This PR fixes a regression where the numCSE statistic was being
incremented twice for a single operation elimination. The numCSE counter
is already internally incremented within the replaceUsesAndDelete
function. Manually incrementing it again after the function call leads
to an inaccurate total count. This is part of the
https://github.com/llvm/llvm-project/pull/180556.
[PAC][clang] Use `Error` behavior for ptrauth module flags
Previous use of `Min` for `ptrauth-elf-got` and `ptrauth-sign-personality`
module flags was introducing a risk of silent decrease of security
during module merge.
[LoongArch] Implement canMergeStoresTo to avoid crash while NoImplicitFloat attribute is set (#188005)
Currently, when the `NoImplicitFloat` attribute is set, consecutive
64-bit load
and store operations will be combined into 128-bit ones, which is
illegal
because that attribute makes floating point and SIMD unavailable.
By implementing the canMergeStoresTo, we can prevent this incorrect
merging.
Fixes https://github.com/llvm/llvm-project/issues/186645
[MLIR][ArithToLLVM] Fix index_cast on memref types generating invalid LLVM IR (#189227)
`arith.index_cast` and `arith.index_castui` accept memref operands (via
`IndexCastTypeConstraint`), but `IndexCastOpLowering::matchAndRewrite`
did not handle this case. When the operand was a memref, the conversion
framework substituted the converted LLVM struct type, and the lowering
incorrectly attempted to emit `llvm.sext`/`llvm.zext`/`llvm.trunc` on a
struct value, producing invalid LLVM IR.
Since LLVM uses opaque pointers, all memrefs with integer or index
element types lower to the same `\!llvm.struct<(ptr, ptr, i64, ...)>`
type, making `arith.index_cast` on memrefs a no-op at the LLVM level.
Add a check that treats the memref case as an identity conversion (same
as the same-bit-width path).
Fixes #92377
Assisted-by: Claude Code
[MLIR] Validate APInt bitwidth in IntegerAttr::get(Type, APInt) (#188725)
IntegerAttr::get(Type, APInt) did not validate that the APInt's bit
width matched the expected bit width for the given type. For integer
types, the APInt width must equal the integer type's width. For index
types, the APInt width must equal IndexType::kInternalStorageBitWidth
(64 bits).
Passing an APInt with the wrong bit width could cause a
non-deterministic crash in StorageUniquer when comparing two IntegerAttr
instances for the same type but with different APInt widths.
This commit adds assertions in the get(Type, APInt) builder to catch
such misuse early in debug builds, providing a clear error message at
the call site rather than a cryptic crash in the storage uniquer.
Fixes #56401
Assisted-by: Claude Code
[Hexagon] Use __HVX_IEEE_FP__ to guard protos that need -mhvx-ieee-fp (#184422)
Hexagon clang recently started to define __HVX_IEEE_FP__ when the
-mhvx-ieee-fp option is specified. Guard the intrinsic macros for
instructions that should only be available with -mhvx-ieee-fp with
__HVX_IEEE_FP__.
Additionally, the following NFC changes are included:
- NFC: Remove guards around HVX v60 intrinsic macros
Hexagon v60 is the oldest Hexagon version that supports HVX so these
guards were redundant. Presence of HVX is guarded separately, once
per the whole file.
- Remove comments from closing guards (HVX protos)
These comments served very limited function as they only guard
one macro. Also, they were incorrect. Instead of fixing remove them.
This will also reduce by the factor of two the amount of changes
when guarding conditions change.
[Hexagon] Define __HVX_IEEE_FP__ when -mhvx-ieee-fp is enabled (#183829)
Add a __HVX_IEEE_FP__ define when the compiler is invoked with
-mhvx-ieee-fp flag
