[IR] `select` should reject token-like types
Target extension types with the IsTokenLike property are meant to behave like
tokens. The change in #154620 already rejected such types in phi nodes, function
arguments, function return types and call parameters. Added this missing check
in SelectInst::areInvalidOperands().
Some DirectX lit tests deliberately use token-like types in Phi or Select
instructions, while disabling the verifier. This change disables the verifier in
one more test to keep it working.
Assisted-By: GPT 5.6 Sol
[SPIRV] Add support for the `SPV_EXT_long_vector` extension (#210279)
This adds support for
<https://github.khronos.org/SPIRV-Registry/extensions/EXT/SPV_EXT_long_vector.html>,
which (in brief) allows any and all vector ranks to be used in SPIR-V,
via a new `OpTypeVectorIdEXT` type. The latter can be used anywhere an
`OpTypeVector` can be used.
The change itself is a bit of a chonk because:
- it was necessary to deal with oddities around single element vectors
(`IRTranslator` really does not like them);
- handling and interacting with vectors is pretty spread out.
---------
Co-authored-by: Marcos Maronas <mmaronas at amd.com>
[GVN] Assign unique VNs to calls with operand bundles (#211784)
Call instructions with operand bundles may be assigned the same value
number, even if operand bundles differ. The GVN may eliminate one of the
calls in favour of another and drop one of the operand bundles.
Work around this by assigning unique value numbers to calls with operand
bundles.
[X86] Improve PDEP/PEXT instructions scheduling on znver1/znver2 models (#217304)
znver1/znver2 have notoriously bad implementations of the PDEP/PEXT
scalar instructions, just using the WriteMicrocoded tag isn't useful as
it can't give any indication of the awful effect on ALU pipes or uops
flooding.
The measurements on uops.info/Agner are all over the place (and are very
input dependent), so I've taken an average of the worse case to at least
give the scheduler something to work with.
We've ignored these so far, but now we're close to generating
llvm.pdep/pext intrinsics (and scalarizing vector implementations).
[analyzer] Print comparison literals with the right signedness (#219136)
`ConditionBRVisitor::patternMatch()` streamed the literal operand of a
comparison through `APInt`'s stream operator, which hardcodes `print(OS,
/*isSigned=*/true)`. Any unsigned literal with its top bit set therefore
rendered as a negative number, so a path note could claim an unsigned
variable equals a value it cannot hold:
```
note: Assuming 'x' is equal to -1 // x is 'unsigned'
note: Assuming 't' is >= -446744073709551616 // t is 'unsigned long long'
```
The note describes the *other* operand of the comparison, so print the
literal the way that operand would hold it: take the signedness from
that operand rather than from the literal. The caller already has both
operands, so it just passes the opposite one in.
Note that keying off the literal's own type does not work. In
`macros.cpp` an `int` is compared against `UINT32_MAX`, and there `-1`
is the correct rendering -- that variable genuinely holds `-1`, and
[11 lines not shown]
[lldb] Use optional<size_t> in FindArgumentIndexForOption (#218716)
When compiling lldb for Arm 32-bit I got this warning:
llvm-project/lldb/source/Interpreter/Options.cpp:1037:19: warning:
result of comparison of constant 18446744073709551615 with expression of
type 'std::tuple_element<1U,
std::pair<size_t, size_t>>::type' (aka 'unsigned int') is always true
[-Wtautological-constant-out-of-range-compare]
1037 | if (val_idx != LLDB_INVALID_INDEX64 && val_idx <
args_copy.size()) {
| ~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~
LLDB_INVALID_INDEX64 is a uint64_t, but val_idx is a size_t, which is
32-bit on a 32-bit system.
I could fix this by changing val_idx's type or adding a
LLDB_INVALID_INDEXSIZET, but I thought it would be better to not have to
think about sizes at all.
[3 lines not shown]
[C++20] [Modules] Preserve placement new and operator for ADL in Reduced BMI (#219145)
Close https://github.com/llvm/llvm-project/issues/218246
The root cause of the issue is, the placement new and operator for ADL
is not directly referenced and they are removed in reduced BMI. This is
not correct. This patch fixes it.
[lldb][Linux][ARM] Fix build after ptrace header removal (#219148)
f69fbd6415ab3a0743d14f0e345f9b61720ce187 / #218045 removed our own
ptrace header, which was fine elsewhere but on Arm we also included
asm/ptrace.h.
We don't have to though, and removing it fixes build errors like:
```
In file included from /buildbot/lldb-arm-ubuntu/llvmproject/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp:31:
/usr/include/arm-linux-gnueabihf/sys/ptrace.h:74:3: error: expected identifier
74 | PTRACE_GETREGS = 12,
| ^
```
Which is because asm/ptrace.h has already defined PTRACE_GETREGS to 12.
[flang][fir] do not move alloca outside parallel regions in StackArrays (#218679)
The StackArrays and AllocationPlacement passes where moving allocations
outside of do concurrent and OpenACC region when turning them from
allocmem to alloca.
Fix this by replacing the existing OpenMP special handling by the
generic `getAllocaBlock` helper.
Also prevents the insertion of stacksave/stackrestore when looplike
operations have the AutomaticAllocationScope traits since they are
alreay in charge of the cleanup (otherwise stacksave/stackrestore were
inserted at the beginning and end of acc.loop when turning alloca into
allocmem which makes later analysis harder while they are not needed).
In the update of getAllocaBlock, I also noticed it was testing parent
parallel regions in "dialect order" instead of returning the closest
parent.
Assisted-by: AI
[VPlan] Recognize disjoint 'or' in getSCEVExprForVPValue (#218405)
Handle 'or disjoint' as an add expression in getSCEVExprForVPValue to
detect more strided access patterns.
No nowrap flags are added here since SCEV expressions are unique by
structure and would leak them to unrelated additions computing the same
value.
[AArch64][SVE] Support copy of PPR2 register class in copyPhysReg (#216303)
This fixes the following crash, which was observed after landing
#209484: https://clang.godbolt.org/z/YG1r63oT3
build_llvm_release.bat: Disable clang-tools-extra for stage0 builds (#218806)
stage0 just needs to build the minimal toolchain so clang-tools-extra is
not necessary.
[libc][AArch64] Make mathvec/aarch64/expf.cpp compile big-endian (#218945)
The macros `V2` and `V4`, defined in `common.h`, are intended to
construct an initializer expression for a vector of 2 or 4 copies of the
same value, used in constant data initialization. But they provoke a
compiler warning when used in a big-endian build: "vector initializers
are not compatible with NEON intrinsics in big endian mode". Usually
this warning is upgraded to an error, and causes the libc compilation to
fail, or at least the compilation of `mathvec/aarch64/expf.cpp` in the
tests.
ACLE doesn't specify any `constexpr`-compatible way to initialize a
vector. The next best thing is to store the lane value just once in the
expf data structure, and use a `vdupq_n` intrinsic to splat it across
multiple lanes.
In this patch, I've introduced a system of macros that does that in a
big-endian build, but keeps the existing strategy little-endian, in case
it's faster.
[lldb] Stop a cached read at an invalid range (#218997)
`MemoryCache::Read` refused a read only when its first byte sat in a
range
the process had recorded as invalid. A read whose interior met such a
range
was served in full, out of a cache line fetched straight across it,
which is
what the `FIXME` in that function described:
```
// FIXME: We should do a more thorough check to make sure that we're not
// overlapping with any invalid ranges (e.g. Read 0x100 - 0x200 but there's an
// invalid range 0x180 - 0x280).
```
With an invalid range at `[0xE010, 0xE020)`, a 64-byte read at `0xE000`
returned 64 bytes and a success status.
[5 lines not shown]
[WebAssembly] Avoid same-block dominance walks in RegStackify (NFCI) (#218369)
RegStackify asks whether one use dominates the others.
But when both uses are in the same block, MachineDominatorTree answers
that by walking the block from the start.
Use the SlotIndexes already available here instead.
This avoids repeatedly walking over DBG_VALUEs and other instructions in
large blocks.
(cherry picked from commit fad811bffe33b7858a46ccb76259e989d780b6b0)
workflows/release-binaries.yml: Only dump the wix logs on failure (#218810)
There is currently a bug in the path on ARM64 Windows, so this step
always fails. Running it after a successful build doesn't make much
sense anyway since since we don't need to see the logs for a good build.
Also, we risk having it fail the whole job even after a successful build
(like what is currently happening on ARM64 Windows), so that's another
reason only to run this when the bulid fails.
(cherry picked from commit c3badbb25e225b8ea428c65b7729c7f64efdd245)
[AArch64] Use SDValue to pass to vectorToScalarBitmask. (#218717)
Passing a SDNode loses whether the value is result 1 from a
uadd_with_overflow. Pass the SDValue instead.
Fixes #218668
(cherry picked from commit 14bbf16732524a83ca0b83686988db799dabb974)
If the address of the isa_pointer is returned as an error don't ask if it is a tagged pointer (#213163)
The answer isn't right and the wrong type might stick and cause
downstream failures.
Note, the correct solution to this is to distinguish between "couldn't
get the address" and "got a real value of LLDB_INVALID_ADDRESS" but
piping an optional all the way down and then through all the uses is an
intrusive change which I don't have time for right now. That only risk
is that this really IS a tagged pointer with the value
LLDB_INVALID_ADDRESS, so this seems an acceptable workaround.
I ran across this when debugging the ObjC test failures in the ObjC
testuite after 8b9cce358bef26ae4cb9275dd6a43f903bafbaa0. This patch
clears up all those testsuite failures, which should stand as a test for
this patch when I resubmit that change.
(cherry picked from commit 8fbdc8cd027176fb54c5fbcd7688fe78eed0154f)
Use static_pointer_cast to do SyntheticChildrenSP -> ScriptedSyntheticChildrenSP (#216181)
FormatManager::GetSyntheticForType was taking a pointer out one shared
pointer and making a new shared pointer referring to it which messes up
the lifecycle of the object.
This is just a little thinko from the original implementation. We do the
same thing in several other places in the TypeCategory, etc. and it's
done correctly in all the other places.
I'm not adding a test here because trying to guess what you have to do
to cause one or the other shared_pointer to get their reference count to
0 isn't particularly stable.
The testing for SBTypeSynthetic is pretty minimal - it would be better
to write a complete test for this class, which would have tripped this.
But that's a bigger task, and I want to get this obvious crasher fix in
now.
[5 lines not shown]
[analyzer] Fix assertion in BitwiseShiftChecker from getExtValue (#218940)
`APSInt::getExtValue()` asserts `isRepresentableByInt64()`, which for an
unsigned value means it must fit in 63 bits. `checkOvershift()` called
it unguarded on a solver-derived lower bound, so any bound at or above
2^63 crashed with:
`Assertion 'isRepresentableByInt64() && "Too many bits for int64_t"'
failed.`
```c++
unsigned huge_right_operand_symbolic(unsigned x, unsigned long long t) {
if (t < 18000000000000000000ULL)
return 0;
return x >> t; // no-crash: gh #218867
}
```
Format the `APSInt` directly instead. Its stream operator honors the
value's own signedness, so bounds of any width print correctly, matching
[24 lines not shown]
[gold] Use ld.bfd for tests (#130981)
The gold linker is deprecated and no longer part of the default binutils
source distribution. LLVM's gold plugin, despite its name, does not
actually require the gold linker, it is compatible with any linker
implementing the necessary plugin interface, including the normal ld.bfd
linker. However, our tests for the gold plugin currently require the
gold linker.
This PR switches the tests to the ld.bfd instead, to the degree that
this is possible. A number of tests keep using gold, because they use
flags that ld.bfd only supports in very recent versions
(`--section-ordering-file` since 2.43 and `--start-lib` since 2.47).
The `thinlto.ll` test is changed to use `test -s` instead of `test -e`,
because ld.bfd will always create the (empty) output file, even if
`--plugin-opt=thinlto-index-only` is specified.
The `linkonce_odr_unnamed_addr.ll` test adds some uses of the
[9 lines not shown]
[RISCV] Support version 0.9 of Zvabd (#218576)
This commit includes support for the ARC approved version of Zvabd
(https://github.com/riscv/riscv-isa-manual/pull/3279), including code
generation support and intrinsic support. Intrinsic doc:
https://github.com/riscv-non-isa/riscv-rvv-intrinsic-doc/pull/436.
In addition, the constraint `DestEEW = EEWSEWx2` is now used for
widening vwabda[u] instructions for correct metadata.
Co-authored-by: renndong <liumingliang.dev at bytedance.com>
Co-authored-by: Pengcheng Wang <wangpengcheng.pp at bytedance.com>
Assisted-by: AI
[LLD][COFF] Set the Thumb bit on locally imported ARMNT function poin… (#215919)
When a dllimport reference turns out to be locally defined, lld synthesises the
__imp_ pointer itself in LocalImportChunk. On ARMNT it was written unadjusted, so
an indirect call through the slot requests ARM state on a Thumb-only target.
Adjust it as DelayAddressChunk and AddressTableChunk already do, excluding data:
dllimport of a locally defined variable is valid and its pointer must not change.
Assisted-by: Claude Opus 5 (Anthropic)
[StackSafety] Skip a caller's callee operand typed GlobalVariable (#216565)
The callee operand of a call can be a function pointer global. A
GlobalVariable is not analyzable locally. Otherwise the compiler could
crash.
Claude (Claude-Opus-5) noreply at anthropic.com
[Flang][MLIR] Move setOpenMPIntegerWrapAround function into the OpenMP dialect (#217448)
- Fixed the linker error: `undefined reference
to'mlir::omp::IntegerWrapAroundAttr::get(mlir::MLIRContext*, bool)'`
mentioned in mentioned in
[PR#214165](https://github.com/llvm/llvm-project/pull/214165#issuecomment-5323821248)
by moving the `setOpenMPIntegerWrapAround(...)` helper function out of
`flang/Tools/CrossToolHelpers.h` and placed it into the OpenMP dialect
utilities.
