[clang] Fix filler handling for new expression with unspecified bound. (#182203)
Array new with a runtime bound requires an "array filler" to initialize
elements which aren't explicitly initialized. Array new with an
unspecified bound doesn't need this; the array length is a compile-time
constant. Make sure SemaInit doesn't confuse the two cases.
Fixes #81157.
[Hexagon] Support .reloc asm directive (#183849)
.reloc directive can be used in user assembly programs and created
internally by LLVM. In addition to Hexagon relocations, there are a few
generic names (BFD_RELOC_NONE, BFD_RELOC_8, BFD_RELOC_16,
and BFD_RELOC_32) that are mapped to Hexagon ones.
[LLDB] Allow one-line summaries in the presence of synthetic child providers (#184926)
This is driven by the Swift language. In Swift many data types such as
Int, and String are structs, and LLDB provides summary formatters and
synthetic child providers for them. For String, for example, a summary
formatter pulls out the string data from the implementation, while a
synthetic child provider hides the implementation details from users, so
strings don't expand their children.
rdar://171646109
[VPlan] Scalarize to first-lane-only directly on VPlan
This is needed to enable subsequent https://github.com/llvm/llvm-project/pull/182595.
I don't think we can fully port all scalarization logic from the legacy
path to VPlan-based right now because that would require us to introduce
interleave groups much earlier in VPlan pipeline, and without that we
can't really `assert` this new decision matches the previous CM-based
one. And without those `assert`s it's really hard to ensure we properly
port all the previous logic.
As such, I decided just to implement something much simpler that would
be enough for #182595. However, we perform this transformation before
delegating to the old CM-based decision, so it **is** effective
immediately and taking precedence even for consecutive loads/stores
right away.
Depends on https://github.com/llvm/llvm-project/pull/182592 but is stacked on
top of https://github.com/llvm/llvm-project/pull/182594 to enable linear
stacking for https://github.com/llvm/llvm-project/pull/182595.
Don't pass RecipeBuilder
Legacy calls `setRecipe` on all processed recipes but really queries `getRecipe`
for memory operations only, that we don't touch in the scalarization as that
happens after all memory recipes has been processed.
[lldb] Declare types of Python synthetic signatures (NFC) (#184914)
Similar to the changes in #182892
---------
Co-authored-by: Ebuka Ezike <yerimyah1 at gmail.com>
[NFC][VPlan] Add initial tests for future VPlan-based stride MV
I tried to include both the features that current
LoopAccessAnalysis-based transformation supports (e.g., trunc/sext of
stride) but also cases where the current implementation behaves poorly,
e.g., https://godbolt.org/z/h31c3zKxK; as well as some other potentially
interesting scenarios I could imagine.
The are two test files with the same content. One is for VPlan dump change of
the future transformation alone (I'll update `-vplan-print-after` in the next
PR), another is for the full vectorizer pipeline. The latter have two `RUN:`
lines:
* No multiversioning, so the next PR diff can show the transformation itself
* Stride multiversionin performed in LAA, so that we can compare future
VPlan-based transformation vs old behavior.
[Clang][ExprConst] Handle APValue::LValue in BitCast (#184865)
Instead of marking the branch unreachable, emit an unsupported type
diagnostic and return false when encountering `APValue::LValue` in
`APValueToBufferConverter`.
A good example of this is:
```
long fn() {
return __builtin_bit_cast(long, (long)&fn);
}
```
Although `&fn` itself is a pointer type, the cast `(long)` converts it
to an integer type, which passes `checkBitCastConstexprEligibilityType`.
Thus, eventually, we see it in Converter, which does not expect an
LValue.
Fixes https://github.com/llvm/llvm-project/issues/44991
[mlir] Fix assertion crash in test-symbol-uses with nested modules (#185069)
The `SymbolUsesPass` walked all nested `SymbolOpInterface` ops in a
module, including those belonging to nested symbol tables (e.g., nested
modules). When an external `func.func` inside a nested module had no
uses in the outer module's body region, it was incorrectly added to
`deadFunctions` for erasure. Since the outer module's `SymbolTable` does
not contain the inner module's symbols, the subsequent
`table.lookup(name)` assertion would fail with:
Assertion `table.lookup(name) && "expected no unknown operations"`
failed.
Fix by only tracking functions that are direct children of the enclosing
module, skipping functions owned by nested symbol tables.
Fixes #60583
Assisted-by: Claude Code
clang: Simplify emission of uniform-work-group-size attribute
This wasn't strictly using the LangOpt field for this property,
and hardcoding the OpenCL version. It was also going out of its
way to specifically annotate specific calling conventions. Just
unconditionally emit it on all functions. The uniform work group
assumption must hold in the entire module, not just the entrypoint.
This also theoretically saves work for the attributor propagation.
This will avoid the need to repeat the same logic in builtin function
codegen.
[libc++] Add alias template for __strip_signature::type (#181955)
Simplifying the internal implementation by providing a more concise
way to access the underlying type within the __strip_signature class.
[NFC][VPlan] Split `makeMemOpWideningDecisions` into subpasses
The idea is to have handling of strided memory operations (either from
https://github.com/llvm/llvm-project/pull/147297 or for VPlan-based
multiversioning for unit-strided accesses) done after some mandatory
processing has been performed (e.g., some types **must** be scalarized)
but before legacy CM's decision to widen (gather/scatter) or scalarize
has been committed.
And in longer term, we can uplift all other memory widening decision to
be done here directly at VPlan level. I expect this structure would also
be beneficial for that.
