[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
[AArch64][GISel] Do not bitcast nonpower2 element size G_CONCATs (#189911)
This currently gets stuck in a loop, unable to make progress throught
the
bitcast concat. Limit it to legal element sizes so that we always make
progress
and at least fall back to SDAG as opposed to crashing or getting stuck.
[lldb] Replace OptionalBool with LazyBool (#189652)
The only difference between them is that OptionalBool's third state
is "unknown" and LazyBool's is "calculate". We don't need to tell
the difference in a single context, so I've made a new eLazyBoolDontKnow
which is an alias of eLazyBoolCalculate.
[mlir][NFC] Remove conditionally unused type alias (#189894)
The `RawType` type alias is unused (`-Wunused-local-typedef`) in build
with asserts deactivated. In combination with `-Werror`, this causes
builds to fail.
Signed-off-by: Lukas Sommer <lukas.sommer at amd.com>
[clang][bytecode] Revisit reference variables as constexpr-unknown in C++26 (#187918)
When revisiting `const T& range = f(T());`, we do mark the variable for
`range` as constexpr-unknown, but not the temporary variable we create
for `T()`. Change that.
Then we also need to ignore constexpr-unknown pointers in
`CheckInvoke()`.
Fixes https://github.com/llvm/llvm-project/issues/187775
[AMDGPU] Disable generic DAG combines at -O0 to preserve debuggability.
Disable generic DAG combines for AMDGPU at -O0 via disableGenericCombines()
to preserve instructions that users may want to set breakpoints
on during debugging.
Since power-of-2 division/remainder for types > i64 was dependent on
DAG combine optimizations, added shouldExpandPowerOf2DivRem()
to request IR-level expansion for these cases at -O0.
Made-with: Cursor
[CoroSplit] Drop assumption that promise alloca is not accessed before coro.begin (NFC) (#189521)
There is an inconsistency in that the code assumes the promise alloca is
not modified before coro.begin, yet it handles such accesses later. This
patch proposes dropping that assumption and analyzing accesses before
coro.begin from the outset, allowing #189295 to erase promise alloca
without analyse it afterwards.
[Clang][HIP] Deprecate __hip_atomic_* builtins
Emit -Wdeprecated-builtins warnings for all __hip_atomic_* builtins,
pointing users to their __scoped_atomic_* equivalents.
Provide a fixit when the scope is a compile-time constant and there is a direct
mapping from the HIP builtin to a Clang builtin. The compare_exchange builtins
differ in how they accept the desired value, so only a warning (without a fixit)
is emitted for those.
Assisted-By: Claude Opus 4.6
[C++20] [Modules] Fix thread_local variable handling in modules (#189796)
Close https://github.com/llvm/llvm-project/issues/189415
The function shouldVarGenerateHereOnly should also handle thread_local
variables, not just static variables. This fixes incorrect code
generation for thread_local variables in named modules.
[msan] Add missing non-mem PMOV handling (#189768)
This adds support for the remaining non-memory PMOV intrinsics, using
the existing handlers.
handleAVX512VectorDownConvert() is slightly updated to handle cases
where there are fewer than 8 output elements (for which the mask is
still supplied as 8 bits).
[MLIR] convert ConvertToEmitCPatternInterface to ODS (#188621)
This PR converts `ConvertToEmitCPatternInterface` dialect interface to ODS. Also makes changes to derived classes.
[DA] Revise test `PR188098.ll` (NFC) (#189564)
This patch revises the test `Analysis/DependenceAnalysis/PR188098.ll`
added in #189428, primary to improve readability. I confirmed that this
test cashes without the change added in #188098.