[AMDGPU] Add object linking support for LDS and named barrier lowering in the middle end
This is the first patch in a series introducing object linking support for
AMDGPU.
This PR adds the -amdgpu-enable-object-linking flag to enable object linking in
the backend. It also updates the AMDGPULowerModuleLDSPass and
AMDGPULowerExecSync passes to support lowering LDS and named barrier globals
when object linking is enabled.
[Clang] Track constraint's SubstIndex only if it contains outer parameter packs (#191484)
I believe that is the intent of SubstIndex in AssociatedConstraint.
So this enforces the checking explicitly, in case nested SubstIndexes
confuses our poor constraint evaluator.
I reverted the previous fix 257cc5ad89840cdfba4affcc8fe62cf9d02d9017
because that was wrong.
As a drive-by fix, this also removes an strange assertion and an
unnecessary
SubstIndex setup in nested requirement transform.
No release note because this is a regression fix.
Fixes https://github.com/llvm/llvm-project/issues/188505
Fixes https://github.com/llvm/llvm-project/issues/190169
[clang-doc] Avoid merging into default Info types
When merging into arenas, the code assumed that all using a default
constructed info would be safe, since in the merge we replace any
differing data. However, that appears to be a risky assumption, due
to default initialized members participating in comparisons, and
other operations, leading the program to read garbage data in some
cases. Earlier patches added default initializers to these fields,
but we should prefer (which the old code used to do) to just start
with properly initialized and complete data from the start.
This patch updates the remaining Info types to have copy constructors
that support choosing the arena to allocate into. This is already the
strategy used in several places to avoid use after free bugs. Since
the handling is now uniform, we can simplify things a bit at the same
time and extract the cloning operation into a helper, making the logic
very clear.
This should avoid any potential pitfalls or missed cases that resulted
in the errors discover after landing #190054.
[lldb][Platform] Use the module's FileSpec instead of the script's FileSpec when checking LoadScriptFromSymFile setting (#191473)
We were incorrectly passing the script's `FileSpec` into
`GetScriptLoadStyleForModule`. Meaning if a script name wasn't actually
the same as the module name, the `target.auto-load-scripts-for-modules`
didn't take effect.
This patch passes the module's `FileSpec` instead. For `dSYM`s we save
the original `FileSpec` because the loop tries to strip extensions until
it finds a script. But we still want to use the module's name.
**AI Usage**:
- Used Claude to write the unit-test skeletons. Then reviewed/adjusted
them manually
zstd: disable weak-symbol tracing hooks in the kernel
zstd's tracing API (zstd_trace.h) declares ZSTD_trace_compress_begin()
and friends as __attribute__((weak)) externals, gated on the
ZSTD_HAVE_WEAK_SYMBOLS compile-time probe. That probe has covered
x86_64 and i386 since at least zstd 1.5.6, and was extended to aarch64
and riscv in 1.5.7.
In a static kernel image there is no dynamic linker to patch the PLT GOT
entries at runtime. On amd64 the undefined weak symbols resolve directly
to NULL, so the "!= NULL" guard in the zstd source correctly suppresses
every call through the stubs. On aarch64 and riscv the ABI requires
GOT-based indirection for external calls: the PLT stub address is
non-NULL, the guard passes, and the call lands in an uninitialized GOT
slot. Because this happens before exception handlers are in place the
machine resets silently, making the kernel unbootable after the zstd
1.5.7 import.
The upstream-supported suppression is ZSTD_NO_TRACE (zstd_internal.h),
[8 lines not shown]
[AMDGPU][Scheduler] Use MIR-level rematerializer in rematerialization stage
This makes the scheduler's rematerialization stage use the
target-independent rematerializer. Previosuly duplicate logic is
deleted, and restrictions are put in place in the stage so that the
same cosntraints as before apply on rematerializable registers (as the
rematerializer is able to expose many more rematerialization
opportunities than what the stage can track at the moment).
Consequently it is not expected that this change improves performance
overall, but it is a first step toward being able to use the
rematerializer's more advanced capabilities during scheduling.
This is *not* a NFC for 2 reasons.
- Score equalities between two rematerialization candidates with
otherwise equivalent score are decided by their corresponding
register's index handle in the rematerializer (previously the pointer
to their state object's value). This is determined by the
rematerializer's register collection order, which is different from
[10 lines not shown]
A binary without a PT_LOAD exec segment would later read a pinsyscall table
and damage it strangely. Such a binary cannot actually run, but we should
avoid the internal pinsyscall table damage, and fail the execve with EINVAL.
reported by Stuart Thomas
ok guenther
Emacs Lisp ports framework: Overhaul
This overhaul introduces four key changes to the elisp ports framework:
1. Remove support for packaged byte-compiled elisp.
The primary motivation is to remove a large number of flavor-specific
packages and to simplify the ports tree. As an example, supporting
byte-compiled elisp for devel/tablist required six packages, one for
each flavor of editors/emacs and editors/emacs-devel. With over 100
elisp ports and requests for new Emacs flavors, this was
unmanageable.
2. Install configuration to integrate with Emacs's native compilation
machinery, allowing elisp from ports to be compiled into the standard
cache under the user's home directory.
This matches the behavior of GNU ELPA packages and generally results
in a faster experience. Speedups vary depending on the
[21 lines not shown]
