[qt/clang/llvm-project]: Summary of bulk changes made

Git repository change summary for qt/clang/llvm-project
Pushed by mirror-service into branch 'upstream/users/arsenm/amdgpu/use-module-flag-xnack-sramecc'.
Changed from da003dfdf8ca196f2f883dd424f8dc5b03efa66e to ee121ec498b072dbf797618c2456f616b8c9f76f
Acknowledgement was received that this change introduces only existing code that has been pushed to another public open source repository.

This change contains the following new commits:

Git commit ee121ec498b072dbf797618c2456f616b8c9f76f by Matt Arsenault on 20/07/2026 at 17:27..
AMDGPU: Use module flags to control xnack and sramecc

This ensures these ABI details are encoded in the IR module
rather than depending on external state from command-line flags.
Previously, these were encoded as function-level subtarget features.
The code object output was a single target ID directive implied
by the global subtarget. The backend would previously check if a
function's subtarget feature mismatched the global subtarget. This
is avoided by making xnack and sramecc module-level properties from
the start. This also provides proper linker compatibility
enforcement, moving the error point earlier.

The old encoding was also an abuse of the subtarget feature system.
Subtarget features are a bitvector, and later features in the string
can override earlier ones. The old handling added a special case
where explicit settings were preserved: ordinarily +feature,-feature
should result in the feature being disabled, but +xnack,-xnack would
preserve the explicit "-xnack" state, which differs from the absence
of any xnack setting.

The new flags are encoded as 0/1, with the "any" case represented
as the absence of the flag. I considered an explicit tri-state unknown
value, but decided against it.

This also removes warnings when using these module flags on targets
that do not support the corresponding feature. Previously, messages
were written directly to stderr instead of using proper diagnostics.
Avoiding the warning reduces burden on frontends to check which targets
require the flags.

For migration purposes, the subtarget features still exist. Currently,
they are still respected in the various binary tools, pending
disassembler changes to determine target ID modifiers from e_flags.
CodeGen requires using the module flags. An error will be raised when
attempting to use the old global subtarget features. These should be
removed after a migration period for frontends to update. Functionality
wise, bitcode autoupgrade should work. Old bitcode will not have the
flags, resulting in a different target ID in the output binary than
expected, but it should run correctly.

New cl::opts exist only because it was inconvenient to update all
tests using multiple xnack modes. Users should never use these.

Co-Authored-By: Claude Opus 4.6 <[email protected]>
https://invent.kde.org/qt/clang/llvm-project/-/commit/ee121ec498b072dbf797618c2456f616b8c9f76f