[Bazel] Fix HTTP linking with MinGW Clang (#215299)
The `//llvm:HTTP` Bazel target passes the MSVC-style `crypt32.lib` and
`winhttp.lib` names to every Windows compiler. Clang in GNU driver mode
treats those names as input paths, so MinGW builds fail instead of
resolving the WinHTTP and CryptoAPI import libraries.
Assisted-by: OpenAI Codex.
[lldb] Fix incorrect Python property bindings in SBExtensions. (#215283)
Several Python property definitions in the SB extension interface files
were incorrectly copy-pasted during the
["Don't use SWIG internals
refactor"](https://github.com/llvm/llvm-project/commit/89b658428bae3b749f174ca79f0fe390451d8f69)
causing properties to shadow earlier definitions instead of exposing new
functionalities.
Rename each duplicate to its intended property name and wire it to the
correct underlying method.
Add add new API tests to cover the issue.
- SBModule: compile_unit -> section.
- SBType: is_function -> is_reference.
- SBTypeSummary is_function_code -> is_function_name.
[clang][Headers] Fix typo in documentation of cpuid.h (#215316)
Fix extended leaf hex value from 0x8000000 to 0x80000000 in the doxygen
comment for __get_cpuid_max, and correct the description of its return
value behavior when CPUID is unsupported.
[SDAG] Make FNEG and FCOPYSIGN expansions handle vectors (#214545)
PR #214341 resolved a bug where the expansion of FABS wasn't correctly
unrolling vector operands before invoking getSignAsIntValue(). This bug
was identified in the expansions for FCOPYSIGN and FNEG, but I didn't
fix it in that PR because I couldn't find a target that triggered these
expansion patterns.
Therefore, this followup PR fixes the bug in case someone someday uses
these codepaths again.
[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
