[MSP430] Use INSERT_SUBREG of IMPLICIT_DEF for anyext. NFC (#242305)
SUBREG_TO_REG means that the instruction defining the subregister also
defined the other bits of the register, which is not true in general
for the i8 operand of an anyext. The high byte of an anyext is
undefined,
which is what INSERT_SUBREG into an IMPLICIT_DEF expresses.
Co-Authored-By: Claude Opus 5.5 <noreply at anthropic.com>
---
<sub>Stack created with <a
href="https://github.com/github/gh-stack">GitHub Stacks CLI</a> • <a
href="https://gh.io/stacks-feedback">Give Feedback 💬</a></sub>
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[MSP430] Fix zext of i8 values not defined by a byte instruction (#242304)
A byte instruction that writes a register clears the high byte of the
register, so a zext of its result can be selected to SUBREG_TO_REG. The
def8 predicate that checks for this excluded a few nodes that are known
not to be selected to such an instruction, but allowed everything else.
This included select and variable shifts, which are expanded into
control flow with a PHI, so the high byte was not cleared on some paths:
```
bit #1, r12
jne .LBB1_2
mov.b r14, r13
.LBB1_2:
mov r13, r12 ; high byte of %x is not cleared
```
Change def8 to only allow nodes that are always selected to a single
byte instruction that writes a register.
[9 lines not shown]
[MSP430] Precommit tests for zext of i8 select and variable shift. NFC (#242303)
These are currently miscompiled: the zext of an i8 value is assumed to
be
free because byte instructions that write a register clear its high
byte, but select and variable shifts are expanded into control flow with
a PHI, so on some paths no byte instruction clears the high byte.
Co-Authored-By: Claude Opus 5.5 <noreply at anthropic.com>
---
<sub>Stack created with <a
href="https://github.com/github/gh-stack">GitHub Stacks CLI</a> • <a
href="https://gh.io/stacks-feedback">Give Feedback 💬</a></sub>
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[HLSL][202x][0010] Update auto keyword to be an HLSL 202x extension instead of 202y (#242101)
Create a 202x diag group. Update the HLSL auto warning to be in the 202x
diag group instead of 202y. Emit the warning if the HLSL version is
below 202x instead of 202y. Add a new test which checks for the warning,
and update existing tests.
Closes #240492
[Flang][OpenMP] Fix non-contiguous and empty target updates (#240503)
Fix compiler lowering and runtime handling of non-contiguous `target
update` operations so multidimensional Fortran sections transfer only
the selected elements.
Preserve physical source strides and scalar-subscript shape, normalize
character bounds and strides, and retain descriptor storage for deferred
`nowait` updates. In libomptarget, merge only consecutive innermost
contiguous dimensions, skip empty updates before presence checks and
transfers, and use 64-bit traversal counts.
Add Flang/MLIR and C/C++/Fortran offload regression coverage for both
transfer directions, multidimensional gaps, empty and `present` updates,
wide characters, and `nowait`.
Includes https://github.com/llvm/llvm-project/pull/235006.
Fixes:
[3 lines not shown]
[SLP]Pack repeated freezes before the vector freeze
The lanes of a vector freeze are frozen independently, so a freeze
repeated in several lanes may get different values. Do not keep the
original lanes with duplicates for freeze nodes, pack the unique values
and reshuffle them.
Pull-request: https://github.com/llvm/llvm-project/pull/242377
[libc] Enable -Werror in baremetal_common.cmake cache file (#241983)
After recent fixes, all the warnings are gone in baremetal builds.
Enable -Werror again so that we can catch warnings as they come.
[BasicAA] Drop invalid nsw flags from linear expressions (#241379)
BasicAA can retain `IsNSW` when folding a linear expression even though
the resulting `V * Scale` can overflow. This happens when combining
scales overflows, when `shl nsw` shifts into the sign bit, or when a
shift distributes over a nonzero offset. The resulting alias checks can
incorrectly return `NoAlias` for equal pointers.
Check the combined scale for signed overflow and route shifts through
`LinearExpression::mul()`. Preserve `nsw` for a shift only when its
multiplier is representable as a positive signed value.
Fixes #241376.
Assisted-by: Claude Code
Assisted-by: OpenAI Codex
[AArch64] Rename WAW helper to denote exact match(NFC) (#242232)
Rename WAW helper to clarify it checks for exact register matches and
distinguish it from a potential future `mayDefOverlapReg()`
[libc] Fix GCC warnings in headers and internal support (#241535)
Building public headers and low-level support libraries with GCC
triggers -Wpedantic on statement expressions and -Wcast-qual on pointer
casts in __containerof, -Wc++20-compat on pre-C++20 char8_t typedefs,
narrowing and uninitialised-variable diagnostics in integer_to_string.h,
and -Wuninitialized in load_unaligned when GCC lowers byte stores into a
GNU vector type via BIT_INSERT_EXPR.
Wrap __containerof in __extension__ while preserving const volatile
qualifiers and casting through __UINTPTR_TYPE__, and drop the obsolete
statement-expression warning suppression from sys_queue_test. Suppress
-Wc++20-compat on GCC 10+ around fallback char8_t typedefs in both
public and proxy headers. Widen acc_remainder to at least size_t and
initialise carry_bit in extract_decimal_digit, and value-initialise the
destination object in load_unaligned alongside LIBC_ALWAYS_INLINE and
trivially-copyable static_asserts on load_unaligned and store_unaligned.
[2 lines not shown]
[clang][deps] Flush the in-process module cache on a background thread
The in-process module cache keeps every PCM built during the lifetime of the
dependency scanning service in memory, and flushes them to disk at the end.
Long-running builds that scan many variants of modules (e.g. with different
search paths or macro definitions) accumulate tens of gigabytes worth of
scanning PCMs this way. Moreover, the final flush is single-threaded and
happens after all scanning work is done.
This PR makes the service start a background thread that flushes each PCM to
disk as soon as it's written, and then replaces its in-memory buffer with the
memory-mapped file. Readers of the in-memory buffer keep it alive on their own
(shared ownership), and importers of the freshly built PCM never wait for the
IO, since the file gets written without holding the entry lock. Reads and
timestamps are still served from memory. The final flush is kept, but only
writes PCMs the background thread failed to write. With
`-no-flush-module-cache`, nothing changes.
I tried several approaches, all measured on a scan of the macOS SDK where
[52 lines not shown]
[clang] Extract built PCMs from their container without copying
When a module is built implicitly, the importing instance extracts the AST
file from the module cache's view of the written PCM and stores a copy of it
in its `InMemoryModuleCache`. That's an extra heap copy of every built PCM,
kept alive for the lifetime of the translation unit.
This PR resolves the FIXME by storing a buffer that keeps the written PCM
alive and exposes just the AST file: the `__clangast` section for PCMs
wrapped in an object file (`-gmodules`), or the whole PCM otherwise. The
in-process module cache now shares the memory of its entry with the
importing instance, and the cross-process module cache gives it the
memory-mapped file.
For a regular implicit modules build importing Foundation and friends, this
reduces peak memory footprint from ~150 MB to ~100 MB. For a TU importing
Foundation with `-gmodules` (31 PCMs), the copy increased the peak memory
footprint by 12-17%.
[clang] Use the module cache's view of built PCMs
When building a module implicitly, the compiler hands the PCM contents to
`ModuleCache::write()` and then extracts the AST file from the PCH container
of its own buffer, storing a copy of it in the `InMemoryModuleCache` of the
importing instance.
This PR makes `ModuleCache::write()` return a buffer with the written
contents, which the importing instance now extracts the AST file from. The
in-process module cache returns a buffer sharing ownership of its entry, the
cross-process module cache returns the written file, read back from the same
file descriptor it was written through (memory-mapped for all but small
files). This is a prerequisite for storing the module cache's view in the
`InMemoryModuleCache` without copying it.
To support this, `writeImpl()` can now read the written file back from the
same file descriptor, guaranteeing we map exactly the contents we wrote and
making it immune to concurrent replacement of the file.
[4 lines not shown]
[clang][deps] Share ownership of buffers in the in-process module cache
Previously, `InProcessModuleCache::read()` returned non-owning references
to buffers stored in the cache entry. Since other threads may be reading
an entry while it gets written, the entry had to keep the buffer it read
from disk alive alongside the written buffer for the lifetime of the
service. This happens whenever a PCM read from disk turns out to be out of
date and gets rebuilt.
This PR stores a single buffer with shared ownership in the entry and
makes `read()` return a buffer that keeps the contents alive. Writing to
the entry now simply replaces the buffer, and the previous one gets released
once the last reader is done with it. This is a prerequisite for evicting
buffers from memory.
Since PCMs read from disk are memory-mapped, the stale buffers didn't add to
the memory footprint, but kept the old files mapped. In an incremental scan
that rebuilds 1010 invalidated PCMs (199 MB), no Clang instance referenced
any of them by the time they got rewritten, so all of them got unmapped right
[2 lines not shown]
[WholeProgramDevirt] Use indirect-call profile counts for fallback branches (#237377)
Fallback and speculative devirtualization always treated the version
check as likely, even when the call already had a value profile showing
how often the direct target was hit. When the profile names that target,
split the total count into the count for the target and the count for
everything else, and use those as the branch weights. Keep the likely
weights when the call has no value profile, when the total count is
zero, or when the profile does not name this target.
[libc] Disable using __float128 on x86_64 Clang prior to 18.1. (#241999)
This fixes the root cause of the post-merge failures for #235008
implementing `swprintf`.
Prior to Clang 18.1, there is an x86_64 bug in `va_arg` for `__float128`
due to the type not being handled in `X86_64ABIInfo::classify` (fixed in
https://github.com/llvm/llvm-project/pull/75156).
https://godbolt.org/z/cWEej49jb compares Clang 17 and 18.1.
This should have been caught earlier by the same LLVM BuildBot running
sprintf_test, but `src/__support/printf_core/printf_config.h` which
configures `LIBC_INTERNAL_PRINTF_CONVERT_FLOAT128` was missing an
include of `include/llvm-libc-types/float128.h`. This meant the `%Q`
conversion cases in sprintf_test were getting compiled out, and it was
by luck that the header include order for swprintf_test triggered the
issue.
Assisted-by: Automated tooling, human reviewed.
[Plugins] Remove CGTestPlugin and add it back as Ciao in examples (#242038)
CGTestPlugin used to test the insertion of passes into the legacy
codegen pipeline via RegisterTargetPassConfigCallback. A LIT test was
running it through llc for the native target and a unit-test checked
that the insertion worked across targets. The unit-test name was
CGPluginTest. This didn't match the filter in LIT, which requires the
names to end in "Tests". I think it never actually ran in CI.
CGTestPlugin predates the time when we enabled examples by default and
was one of the plugins that lived under unittests. In contrast to TestPlugin
and DoublerPlugin, however, it didn't check internal properties of the plugin
interface.
This PR moves the plugin to examples and makes the lit test the single
place that checks it. Motivation for this is to establish a plugin next
to Bye, that allows to test the behavior of codegen plugins in
isolation. There are 2 use-cases for it currently:
[12 lines not shown]
[X86] combineVPDPBUSDPattern - incorrect vector element count (#240821)
Ensure we determine the vector element count from the reduction ROOT,
not the first vector in the chain - to correctly handle cases where the
ROOT is split during reduction
Fixes #240667
