[RISCV] Add SDNPCommutative to riscv_mulhr/riscv_mulhru/riscv_mulq/riscv_mulqr. NFC (#217702)
NFC because no isel patterns make use of this property today.
[NFC] Mark truncated-profile.test unsupported on zos, similar to existing tests that use printf (#217742)
follow up to #211281
Co-authored-by: Wael Yehia <wyehia at ca.ibm.com>
[DWARF] Fix DW_OP_LLVM_user sub-operation name lookup. (#217480)
LlvmUserOperationEncodingString returns a name with a "DW_OP_LLVM_"
prefix, but getLlvmUserOperationEncoding matched the suffix (subop)
name. This patch updates the latter to match the full name.
Assisted-by: LLM
[NVPTX] Honor !atomic.ignore.denormal.mode on atomicrmw fadd
PTX atom.add has a fixed denormal behavior that the program cannot
control: atom.add.f32 flushes denormals on global memory but not on
shared, and atom.add.f16 never flushes. When that disagrees with the
function's denormal mode, the backend expands the atomic into a CAS loop
so the denormal behavior is preserved.
!atomic.ignore.denormal.mode says the denormal behavior of this
particular atomic does not matter, so use the native instruction even
when it disagrees. This is the same thing -nvptx-allow-ftz-atomics does,
except per-instruction instead of per-compilation, which lets a frontend
opt in only the operations it knows about -- notably CUDA's atomicAdd(),
which is defined in terms of atom.add.
Note that -nvptx-allow-ftz-atomics defaults to true, so the new behavior
is only observable with -nvptx-allow-ftz-atomics=false.
Co-authored-by: Artem Belevich <tra at google.com>
[clang][NVPTX] Emit !atomic.ignore.denormal.mode for CUDA atomics
CUDA's atomicAdd() family is defined in terms of PTX atom.add, whose
denormal behavior is fixed by the hardware. Without any annotation the
backend has to assume the function's denormal mode must be honored and
expands these into CAS loops whenever the two disagree. Mark them with
!atomic.ignore.denormal.mode so the native instruction is used.
That covers the __nvvm_atom_*_add_gen_f builtins that atomicAdd(),
atomicAdd_block() and atomicAdd_system() are written in terms of, plus
C11/C++11 atomics under -fatomic-ignore-denormal-mode and the
[[clang::atomic(ignore_denormal_mode)]] attribute, which requires
teaching the NVPTX target about AtomicOptions.
The condition for when the metadata is meaningful is now shared with the
AMDGPU and SPIR-V targets in addAtomicIgnoreDenormalModeMetadata(). It
takes an AllowHalf flag because whether f16 denormals are observable is
target specific: PTX exposes no FTZ control for f16 operations, so
atom.add.f16 never flushes and the opt-in is meaningful there, whereas
[3 lines not shown]
[IR] Generalize !amdgpu.ignore.denormal.mode into !atomic.ignore.denormal.mode
The !amdgpu.ignore.denormal.mode metadata tells the backend that an
atomicrmw fadd need not honor the function's denormal mode, so a native
atomic instruction whose denormal behavior is fixed in hardware may be
used instead of a CAS loop. Nothing about that is AMDGPU specific: NVPTX
has exactly the same problem with atom.add, whose FTZ behavior depends on
the address space and cannot be controlled.
Promote it to a target independent fixed metadata kind,
!atomic.ignore.denormal.mode, and switch the AMDGPU, SPIR-V and OpenMP
producers and consumers over to it. Document it in LangRef, and point
AMDGPUUsage at that description rather than duplicating it.
Existing IR keeps working: AutoUpgrade renames the metadata on atomicrmw
instructions when parsing textual IR and when materializing bitcode. The
upgrade is deliberately scoped to atomicrmw rather than being applied to
every attachment of that name, since that is the only place the metadata
was ever meaningful. Because bitcode can be materialized one function at
[6 lines not shown]
Reland "[flang][FIRToSCF] Recompute a typed induction variable in closed form (#217051)" (#217696)
Reverts llvm/llvm-project#217654
The original PR revealed a bug in our internal project, which is already
fixed. Reland it without any change.
[SampleProfile] Move a couple of options to llvm-profdata (#216233)
This patch moves -md5-prof-sym-list and
-sample-profile-write-eytzinger-name-tables to llvm-profdata.cpp while
renaming the latter to -md5-indexed-tables.
These command line options invoke programmatic setters like
setUseMD5ProfileSymbolList and setUseMD5IndexedTables on the sample
profile writer, much like -use-md5 invokes setUseMD5. These setters
in turn allow external tools to configure the writer programmatically.
[clang][modules] Add `-fmodules-ignore-search-path=<path>` (#217061)
This introduces the search-path counterpart to
`-fmodules-ignore-macro=<macro>`. The named header search `<path>` is
dropped from the context hash of every module and physically removed
from every module-build invocation, and kept only for the translation
unit itself.
The motivating case is a build system that hands every compile a
per-target header search directory (e.g. Xcode's `DerivedSources`) even
though no modules include anything from it. Under
`-fmodules-strict-context-hash` those directories feed every module's
context hash, so an SDK module like Foundation is rebuilt once per
target rather than just once. Ignoring the directories for modules lets
those builds share a single module cache while the TUs that really do
need them keep working.
This only works right when no module needs the path: a lookup that would
have resolved through an ignored path simply fails, exactly as ignoring
[6 lines not shown]
[clang][modules] Cache failures for explicit modules (#215968)
Explicit module files are a (binary) input to the compilation. Just like
any other input file they are expected to not change during compilation.
There's no reason to disable failure caching in the `FileManager` for
them.
[clang][modules] Cache failed stats of additional module maps (#215964)
The additional module maps stored in PCMs are just regular input files
that are not expected to change during compilation. There's no reason to
disable failure caching in the `FileManager` for them.
[IR] Remove dead declarations (#217701)
handleChangedLocation: The corresponding function definition was
removed on January 16, 2024 in commit
d499df02a2508641d67918d7dc41b2e01a4a4114.
noRenameOnPromotion: Added on February 28, 2026 in commit
3e05ab6322cbf2a96362dcacb5907ba519fe552d without a corresponding
function definition.
[flang][OpenMP] Switch SOURCE/SINK to use modifier infrastructure (#217644)
They are instances of the dependence-type modifier in the spec. Putting
them into the modifier infrastructure in the compiler will remove the
need for them to be validated by hand in the future.
[llvm] Propagate dso_local for jump table aliases (#217101)
LowerTypeTests should propagate dso_local if the original function it
would generate an alias for was also dso_local. The benefit here is that
references to the alias can now use PCREL relocs which could prevent
some GOT-generating relocs. Note this is independent of the visibility
and linkage so the types of symbols this would benefit are external
non-hidden dso_local functions.
Gemini was used to help generate tests. I reviewed this to the best of
my ability before posting a PR.
[AMDGPU] Do not propagate ninf/nsz from sqrt when forming rsq (#217599)
These flags only apply to the sqrt, not the quotient
1.0/sqrt(+0.0) is a valid +inf if the fdiv has no ninf, so copying them
makes it poison
[clang-format][docs] Fix grammar in AllowShortFunctionsOnASingleLine (#217625)
## Summary
The `InlineOnly` description said "does not implies `empty`". Change to
"does not imply".
Updated both `Format.h` (source of the style option docs) and
`ClangFormatStyleOptions.md`.
Fixes #195326
Assisted-by: Grok (xAI)
clang/AMDGPU: Use feature bitset for xnack/sramecc queries (#217704)
Complete the conversion of clang from the manual ArchAttr field
to the generated feature bitset.
Co-authored-by: Claude (Claude-Opus-4.8)
[lldb] Only report a symbol server error when the download failed (#217669)
Every symbol locator plugin writes into the same Status, and a plugin
that delivers a symbol file is under no obligation to clear what an
earlier step recorded there, so a search that ended in a download could
still report an error at the user. That contradicts what symbol_error
promises its readers, which is an explanation for a search that came up
short.
Take the download's own answer as the authority on whether anything was
delivered, and consult the Status only when nothing was.
Reported by Coverity (CID 1685292).
Assisted-by: Claude
