[CIR] Accept fixed-width vectors in x86_64 callconv lowering
The CallConvLowering bridge rejects a vector in a parameter or return position,
so a function taking one fails the pass. It also never reads the AVX level,
which is what decides whether a vector wider than 128 bits reaches a register.
A vector is accepted now where the classifier and clang size it the same way,
which means a whole-byte element and a power-of-two width. Scalable vectors and
the other widths stay rejected. The module's AVX level comes from the target
ABI name, as CodeGenModule does. A classifier per level lets a target attribute
raise it for one function. An ABI older than the rule pins every function back
to the module's level. A direct call takes its callee's level, and an indirect
call the level of the function containing it.
CIRGen records target features on a definition but not on a declaration, so a
declaration carrying the attribute is classified at the module's level until
#214986 lands.
Assisted-by: Cursor / claude-opus-5
RuntimeLibcalls: Add sincos to the RISCV runtime libcall set
Inspection of the glibc sources suggests this is generically
available, with the target variance being for long double support.
The set of library functions is a large historical mess I'm attempting
to untangle. The traditional system had a large set of defaulted calls,
but sincos was a case which was explicitly enabled, and I'm assuming
riscv just never got around to adding it. It will be easier to
reorganize the library functions if synthetic architectural glibc
variance is eliminated.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
[Driver][KCFI] Do not invoke cc1 in Driver tests (#215072)
Fixes commit a44318b125ff to avoid using cc1 in Driver tests. Moves
argument validation to CodeGen, and always uses -### for Driver tests.
Build tested on x86_64-only and aarch64-only.
[SimplifyCFG] Avoid scanning functions multiple times in `removeUnreachableBlocks` (#213416)
`markAliveBlocks` scans instructions first to convert unreachable
instructions into `unreachable`, then marks alive successors. When
`iterativelySimplifyCFG` makes some changes, `removeUnreachableBlocks`
will be called again and scan the whole function again, even if
`iterativelySimplifyCFG` is unlikely to introduce new interesting
patterns.
This patch adds a new option `SimplifyInsts` to
`removeUnreachableBlocks`. When it is disabled, `markAliveBlocks` only
performs a BFS traversal.
Although it is possible to cause regressions
(unreachable-multi-basic-block-funclet.ll), it doesn't affect the
optimization result in practice:
https://github.com/dtcxzyw/llvm-opt-benchmark-nightly/pull/877
Compile-time improvement (approx -0.05%):
https://llvm-compile-time-tracker.com/compare.php?from=6a898832ff382b1a288f9eb3bc5cd1f37d0fc29f&to=565856d52880ed13c697e921f498dc400bb76c17&stat=instructions:u
[CIR] Let a record type mark what each member holds
A struct's `padded` bool only says that padding exists somewhere in the record.
It cannot say which member, and it cannot tell compiler-inserted padding from
storage the source declared that holds no ABI data, such as an unnamed
bit-field unit. Those two need to differ, because padding is reusable tail
padding and declared storage is not, so they give different data sizes.
Give each member a mark instead: unmarked for source data, `pad`, or `empty`.
A record is then empty for the ABI when no member holds data, which
`allMembersNonData` reads off the type.
This is the first of three PRs, and nothing populates the marks yet, so
`padded` stays for now. Retiring it before CIRGen fills the marks in would
make every struct claim it has no padding, and the x86_64 classifier would
start counting padding arrays as data with no diagnostic. The CIRGen PR comes
next, then the bool removal PR.
Assisted-by: Cursor / claude-opus-5
[ConstraintElim] Avoid int64_t{1} << 63 when decomposing SHL. (#215058)
int64_t{1} << 63 is defined as INT64_MIN on C++20 and later. In C++17
and earlier, most implementations also already implement this as
INT64_MIN, and UBSan in Clang does not flag it as UB.
Bail out if the shift amount is >= 63, as we would incorrectly add a
negative coefficient to an unsigned constraint.
PR: https://github.com/llvm/llvm-project/pull/215058
[libc++][ranges] Mark LWG4242 as Resolved (#211568)
Closes https://github.com/llvm/llvm-project/issues/148224
The current implementation for the `ranges::distance(I&& first, S last)`
overload already sidesteps the `volatile first` with condition
`sized_sentinel_for<_Sp, __remove_cvref_t<_Ip>>`.
In the commit initially implementing `ranges::distance`
(c965d5448ecdf9a5513983862a78a2ba8f7fbab8), the condition was
`sized_sentinel_for<_Sp, __uncvref_t<_Ip>>` and `__uncvref_t` was just
renamed to `__remove_cvref_t` later. Also, given the overload has been
constrained with `sized_sentinel_for<_Sp, decay_t<_Ip>>`, the condition
always gives the same results as `!is_array_v<remove_reference_t<_Ip>>`
that is indicated by the resolution of LWG4242. So it can be considered
that LWG4242 was implemented in libc++ in LLVM 14.
This commit marks LWG4242 as Resolved and organises the test suite to
better represent both LWG3664 and LWG4242 tests in
[6 lines not shown]
[clang][bytecode] Handle invalid lambda static invokers better (#215091)
Instead of marking it as valid, mark it as constexpr, which means it
won't be valid unless it actually has valid code attached.
[InstCombine] Fold consecutive udivs into a single udiv (#214541)
Extend the existing `(X / C1) / C2 -> X / (C1 * C2)` fold to variable
divisors:
(X udiv Y) udiv Z -> X udiv (Y * Z) if Y * Z does not overflow
Uses willNotOverflowUnsignedMul to prove the product doesn't wrap.
Instruction count is unchanged but a division becomes a multiplication,
similar to the existing cttz-based udiv->lshr fold in visitUDiv.
One-use on the inner div, since otherwise we'd add a mul without
removing
the div. exact only propagates when both divides are exact.
Alive2: https://alive2.llvm.org/ce/z/qV6UJH
Fixes #132908
[mlir][arith][NFC] Make AtomicRMWKind switches exhaustive (#214622)
`getIdentityValueAttr` and `getReductionOp` in `ArithOps.cpp` each
handle 15 of
the 16 `AtomicRMWKind` cases and route the rest through a `default:`
label
carrying `// TODO: Add remaining reduction operations.`
That TODO cannot be completed. The only unhandled kind is `assign`,
which is
not a reduction: it has no identity element (`assign(x, e) = e`, so no
constant
`e` satisfies `assign(x, e) = x`) and no corresponding binary `arith`
op. It is
still a perfectly valid kind elsewhere — `memref.atomic_rmw` lowers it
to an
atomic `xchg` in `MemRefToLLVM.cpp` — it simply has no meaning for these
two
reduction helpers.
[39 lines not shown]
[VPlan] Verify hoist point when hoisting previous value of a recurrence. (#215084)
tryToSinkOrHoistRecurrenceUsers processes the fixed-order recurrences of
a loop one at a time and updates the plan for each of them. Once the
plan has been updated for one recurrence, the properties
hoistPreviousBeforeFORUsers relies on may no longer hold for the
recurrences processed later
Convert dominance assertion that does not hold in all cases (added test
cases) to a bail out, to a crash on the added test.
PR: https://github.com/llvm/llvm-project/pull/215084
[ORC] Remove CallableTraitsHelper (#215089)
CallableTraitsHelper was only used by CallViaEPC.h / CallSPSViaEPC.h,
which were removed in the previous commit. With those gone it has no
remaining users, so remove it and its unit test.
[SLP]Charge spill cost for loop-invariant gathers live over a call
Loop-invariant gathers hoisted to the preheader by
optimizeGatherSequence are live across calls in the loop body and need
spill/reload on targets with call-clobbered vector registers, but were
skipped by getSpillCost. Charge them like other call-crossing values.
Fixes #214555
Reviewers:
Pull Request: https://github.com/llvm/llvm-project/pull/215093
RuntimeLibcalls: Fix reporting incorrectly typed fp128 long double functions
l-suffixed long double math functions are fp128 only when the target's
long double is fp128. The default set provided them on every target that was
not x87 or ppc_fp128, so targets using double as long double wrongly reported
the fp128 l-suffixed functions.
Update tests that were reliant on phantom fp128 calls. These are only available
with glibc on select targets. In cases where the target supports the calls in
some triple, split the tests. In cases where the target has no fp128 library
support, delete the tests.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
[ORC] Remove CallViaEPC.h and CallSPSViaEPC.h (#215086)
These provided EPC calls with pluggable serialization (EPCCaller /
EPCCall / SPSEPCCaller / SPSEPCCall). That role is now filled by the
RTBridge Proxy APIs (rt::Proxy + rt::sps::ProxySpec), and these headers
had no users other than their own unit test, so remove them along with
CallSPSViaEPCTest.
