[lit] Address scaling problems with ProcessPoolExecutor (#214853)
The executor implementation failed to account for how work distributes
across high core count machines. Up to about 64 cores/threads scaling
progresses linearly. However, beyond that the polling overhead, and lack
of scheduling, caused a major regression in high core count machines.
This PR addresses those issues in two ways. First, removes IPC events by
using a SimpleQueue with callbacks, which only fire on events and
removes many polling updates. Second, it batches tests to further limit
the amount of IPC events being tracked. Empirically, even a batch_size
of 2 was enough to dramatically improve overall throughput. This is
tunable through the LIT_BATCH_SIZE environment variable.
Additionally, we change SUBMISSION_WINDOW_PER_WORKER from 4 to 8, as
this was a better balance across both low and high core count machines.
On an AMD Ryzen Threadripper PRO 3995WX 64-Cores, 128 thread, 256 GB RAM
The execution time for check-llvm went from 105.2s to 48.38s, making the
[6 lines not shown]
[ADT][Reassociate] Invalidate stale UniformityInfo entries on instruction erase (#214719)
`GenericUniformityAnalysisImpl::UniformValues` never removes an entry
when its value is erased. Reassociate keeps one `UniformityInfo` for the
whole pass while creating and deleting instructions, so a new
instruction can reuse a freed one's address and inherit its stale
"uniform" verdict instead of the documented divergent default. This
makes rank-boosting depend on heap addresses
Add `forgetValue()` (following the same idea as
`ScalarEvolution::forgetValue`) and call it at Reassociate two erase
sites
As a result of this issue we have a side effect that is reproducible on
https://github.com/llvm/llvm-project/pull/214624: nondeterministic
operand ordering in Reassociate output, because a newly-created
instruction can spuriously be classified "uniform" instead of the
documented default of divergent depending on whether the allocator
happened to reuse a freed instruction address
[3 lines not shown]
[MLIR][Mem2Reg] Add support for memref.alloca_scope (#214221)
This PR implements `PromotableRegionOpInterface` for
`memref.alloca_scope`. This widens the range of programs that can be
processed by Mem2Reg pass.
[flang][OpenMP] Fold canonical loop trip counts during lowering (#215238)
Canonical loop lowering currently materializes the complete trip-count
arithmetic even when the loop bounds and step are compile-time
constants.
Use FirOpBuilder::createOrFold for the comparisons, selects,
subtraction, unsigned division, and addition in the trip-count prologue.
This folds constant trip counts while preserving the existing dynamic
lowering and overflow flags.
Add bare-unroll lowering coverage for ascending, descending, zero-trip,
non-unit-step, dynamic, and i64 loops.
I'm doing this because
1) Surprisingly, no canonicalization pass between lowering and LLVM-IR
translation is doing this already. Folding here saves us building
LLVM instructions just for the middle-end to fold it.
2) This could simplify some analysis for #214115
Assisted-by: Codex
[flang][Lower] Add complex sum reassociation (#214775)
Third part of generalisations requested in #207377.
Extend the experimental split-sum transformation to complex addition and
subtraction chains. Share the signed-term builder across explicitly
supported real and complex categories while keeping integer expressions
excluded.
There are no known effect on benchmarks as a result of this patch.
Assisted-by: Codex
[lldb] Fix MSVC warnings about missing return values (#215313)
MSVC warns with
[C4715](https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4715)
about missing returns in functions where a `switch` over and enum
handles all names enumerators, because the enum could hold unnamed
values. For example, given an `enum class Foo { Bar, Baz }` a function
handles both `Bar` and `Baz` by returning a value, Clang and GCC won't
issue warnings, but MSVC will.
This handles the cases in the two locations I found.
[AMDGPU] Add AMDGPU support for llvm-objcopy (#190020)
llvm-objcopy does not support AMDGPU currently. It does not get target
names where all other tools do but has it's own list. Update the list to
support amdgpu.
https://reviews.llvm.org/D143539https://github.com/llvm/llvm-project/pull/92066
---------
Co-authored-by: Aakanksha Patil <paakan at amd.com>
clang/AMDGPU: Add half typed image gather4 builtin (#213613)
Follow along with the precedent of using an f32 suffix
for the coordinate type. We probably should have had one
builtin that detected the coordinate type.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
[clang][constexpr] Allow IndirectGotoStmt in constexpr functions for C++23 (#213449)
### Summary
P2242R3 relaxed `constexpr` function requirements in C++23 to allow jump
statements such as `goto` and labels inside `constexpr` functions. In
`CheckConstexprFunctionStmt`, `GotoStmtClass` and `LabelStmtClass` were
added, but `IndirectGotoStmtClass` (GNU computed goto) was missed.
This patch adds `case Stmt::IndirectGotoStmtClass:` alongside
`GotoStmtClass` in `CheckConstexprFunctionStmt`.
### Details
- Before this patch, writing `goto *p;` inside a `constexpr` function
resulted in `error: statement not allowed in constexpr function` because
`IndirectGotoStmtClass` fell through to the `default` case in
`CheckConstexprFunctionStmt`.
- With this patch, indirect gotos behave identically to standard gotos
in `constexpr` function bodies:
- Allowed in C++23 mode.
[13 lines not shown]
[SampleProfile] Support Eytzinger layout in SecFuncOffsetTable (#213829)
This patch supports writing SecFuncOffsetTable as an array of
fixed-length uint32_t file offsets parallel to the Eytzinger spans in
SecNameTable for ExtBinary sample profiles.
Without this patch, SecFuncOffsetTable stores pairs of variable-length
ULEB128 integers for GUIDs and file offsets, requiring us to eagerly
load and decode the entire section into an in-memory map.
This patch implements parallel arrays to avoid eager loading:
- In the writer, when -sample-profile-write-eytzinger-name-tables is
set,
SecFuncOffsetTable holds only an array of uint32_t offsets into
SecLBRProfile. The k-th offset entry corresponds to the k-th GUID in the
CSKeys or FlatKeys Eytzinger span of SecNameTable.
- In the reader, when SecFlagEytzinger is set on SecFuncOffsetTable, the
[10 lines not shown]
[BOLT] Skip non-code relocs as function references (#215028)
handleRelocation looked up the referenced function from the resolved
"symbol + addend" address, ignoring the symbol's section. With biased
array indexing the compiler folds a constant into the displacement, e.g.
```
movq const_int_rtx-0x3fe00(,%rax,8), %r14 # R_X86_64_32S const_int_rtx-0x3fe00
```
so the unbiased displacement is not a live address (only disp + rax*8
is), yet it can land inside an unrelated function. BOLT re-anchored the
relocation onto that function and dropped the addend, then during
disassembly registered an interprocedural reference to a mid-instruction
address, producing:
```
BOLT-WARNING: corrupted control flow detected in function ...: an external
branch/call targets an invalid instruction in function ... ; ignoring both
```
[6 lines not shown]
[docs] [kaleidoscope] Remove misplaced backslash from JIT tutorial (#213483)
In order to represent names starting with the string
"InitializeNativeTarget", use `InitializeNativeTarget*` rather than
`InitializeNativeTarget\*`.
[analyzer] Fix -analyzer-output=html assert on reversed and macro ranges
HTMLDiagnostics::HighlightRange guarded against a reversed range by
comparing line numbers, so a same-line reversal - which is what the piece for
an implicit copy constructor carries - reached html::HighlightRange.
Its scan walks from begin to end, ran off the end of the buffer, and asserted:
https://godbolt.org/z/sTb5qfjjd
Invalid position to insert! (RewriteRope.h)
It also added the end token's length itself and then passed a token range to
html::HighlightRange, which measured the token again, this time from the
interior. For most tokens the two cancel, but where the tail re-lexes longer
the highlight reached past the end of the range, e.g. over a trailing ';'.
Use getExpansionRangeInFile(), which rejects reversed and cross-file ranges,
then convert once and tell html::HighlightRange the range is already
char-granular.
[4 lines not shown]
[analyzer] Fix -analyzer-output=sarif crash on macro-expanded ranges
A path piece whose range ends inside a macro expansion aborted the whole
document: https://godbolt.org/z/61vWYcsWj
Cannot create a physicalLocation from invalid SourceRange!
convertTokenRangeToCharRange() built the end with
Lexer::getLocForEndOfToken(), which returns an invalid location for a macro
ID that is not at the end of its expansion, and used it unchecked. The
analyzer's own test corpus hits this in nine files; text and plist output
were unaffected because both already map such ranges to the expansion.
- Use getExpansionRangeInFile(), so the region covers the macro use like the
other two outputs.
- Fall back to a caret when the range is unusable. A thread flow needs a
location per piece, so dropping one would truncate the reported path. This
also stops reversed ranges producing regions with endColumn < startColumn.
[4 lines not shown]
[clang] Reject ranges getExpansionRangeInFile cannot represent (#214461)
getExpansionRangeInFile was extracted verbatim and inherited two
shortcomings
of the original loop, fixed here before the analyzer's SARIF and HTML
consumers
depend on it:
- It mapped the end with getExpansionRange(SourceLocation), which always
reports a token range, so a char-range input was widened by a whole
token.
Now using the getExpansionRange(CharSourceRange) overload, which keeps
the flag.
- It passed reversed ranges through. Consumers walk begin->end; now
returning
nullopt for those, as Lexer::makeFileCharRange already does.
Separate from the extraction so that stays NFC, and out of the consumer
fixes
[7 lines not shown]
[AArch64] Validate fixed-point SCVTF/UCVTF scale operands (#213490)
The fixed-point SCVTF/UCVTF operands are missing the ParserMatchClass
used by
fixedpoint_i32/i64. Symbolic scales can therefore reach the encoder and
hit
its MO.isImm() assertion, while out-of-range scales can alias valid
encodings.
Use Imm1_32Operand and Imm1_64Operand for these operands and add
diagnostics
for both source widths and symbolic scales.
Addresses the scvtf/ucvtf part of #185358. The ext case is tracked by
#185361.
[Flang][OpenMP][MLIR] Materialize groupprivate for target without teams (#214316)
Prior to this change, `groupprivate` variables were only materialized
for teams constructs. A `groupprivate` variable used inside a bare
target region was not materialized.
This commit materializes the `groupprivate` copy on the target construct
itself when target does not contain a teams construct. Making the
behavior equivalent to target teams num_teams(1).
Assisted-by: Opus 4.8
[mlir] Remove dead declaration getSCFMinMaxExpr (#215188)
The corresponding function definition was removed on August 25, 2021
in commit 2de2dbef2a9a0c774acc8bf1ce17d024da5c145e.
[libc] Relax read errno check (#215053)
read_write_test was failing on the libc-arm32-qemu-debian-dbg bot due to
a different errno number. Even though the test has a qemu branch, it did
not kick in because the bot does not set CMAKE_CROSSCOMPILING_EMULATOR
(I assume the tests get run via binfmt_misc).
While we could fix this in the bot config, and the different error
*might* be considered a qemu bug, I don't think this is particularly
relevant for this test, as we're merely forwarding the error number from
the kernel (as such, the errno expectation is more of a test for the
kernel that for libc). I think this okay to relax the check to expect
one of the two reasonable error messages.