workflows/release-binaries: Fix zstd compression (#219587)
23.1.0 was the first e2e release with zstd archives. I noticed that once
it shipped they didn't have a meaningful size improvement over the
pre-existing archives. Turns out this is because by default zstd
compresses over a 128MB window which wasn't large enough to get
meaningful savings. We now use 1GB for this which uses more memory but
should take the archive from the 1.8GB that the xz release is, to ~1gb.
I played around with a few options and this was the best time vs
compress vs memory usage ratio.
Assisted-By: codex
Reapply "[IR] `replaceUsesWith` when aliasing a GV and the use is `dso_local_equivalent`" (#220450) (#222036)
This reverts commit 751ed7b16433d2279286d0765f51cd36edc6d771.
The patch is quite indepdendent from PR #203171, which uncovered the
issue. We decouple them. The fix is tested in the unittest introduced
here. When we reland #203171, we'll add the cfi_dso_local_equivalent.ll
test.
TwoAddressInstruction: Don't repair the unchanged def of a degenerate REG_SEQUENCE (#222053)
When every source operand of a REG_SEQUENCE is undef,
eliminateRegSequence rewrites the instruction in place to IMPLICIT_DEF.
The dead def of DstReg is left untouched, so its live range is already correct.
Passing DstReg to repairIntervalsInRange then makes it re-add an overlapping
segment with a fresh value for the unchanged def, asserting in
LiveInterval::addSegment. Drop DstReg from the repaired set in this case.
Exposed by -early-live-intervals
Co-authored-by: Claude (Claude-Opus-4.8)
[flang][cuda][NFC] Switch to a simple walk for CUFLaunchAttachAttr pass (#222073)
CUFLaunchAttachAttr only sets cuf.proc_attr on outlined CUF kernel
launches (names containing _cufk_). It did that with
applyPartialConversion on the whole module, so the conversion driver
walked host and GPU IR to touch a handful of ops.
Walk gpu.launch_func instead and apply the same filter. I
[AArch64] Form CCMP for CBB and CBH
AArch64ConditionalCompares forms CMP/CCMP chains to transform patterns
such as
Head Head
/ | CmpBB
/ | / |
| CmpBB => / |
| / | Tail |
| / | | |
Tail | | |
| | | |
... ... ... ...
where Head is terminated by a conditional branch and CmpBB contains
a cmp + conditional branch.
We usually try to split any fused conditional branches to be able to
[8 lines not shown]
[AArch64][CMPBR] Fix splitting of CBB/CBH instructions into ext + cmp
We falsely split CBB/CBH instructions by explicitly extending the
second register operand instead of the first one, leading to the
following, wrong codegen:
cbh $wn, $wm, cc, trgt => sxth $wt, $wm
cmp $wn, $wt, cc, sxth
Correct is
cbh $wn, $wm, cc, trgt => sxth $wt, $wn
cmp $wt, $wm, cc, sxth
since cmp with extended register extends it's second, not its first
operand.
[OpenMPOpt] Ask the runtime how many of a block's threads can be workers
The custom state machine gates a thread on InitCB < BlockHwSize - WarpSize,
reconstructing the number of worker threads from the block size on the
assumption that the main thread occupies a whole warp above them. The DeviceRTL
already computes that number, in mapping::getMaxTeamThreads(), and its own
generic state machine gates on it in shouldEnterStateMachine(). Export it as
__kmpc_get_max_team_threads(IsSPMD) and call that instead, so the compiler's
state machine and the runtime's agree by construction rather than by arithmetic
that has to be kept in step with the launch geometry.
The entry point is handed the mode rather than reading it back from
mapping::isSPMDMode(), for the same reason shouldEnterStateMachine() takes it as
a parameter: IsSPMDMode lives in shared memory and only the initial thread
writes it, and in generic mode __kmpc_target_init() returns to the workers
without a barrier in between, so that write is not yet theirs to read at this
point. The compiler passes a constant, a custom state machine being built only
for a generic-mode kernel.
[18 lines not shown]
[OpenMPOpt] Look inside the callbacks the loop runtime functions are handed (#221449)
The `__kmpc_{distribute_,for_,distribute_for_}static_loop_*` functions
take the
loop body as a callback, so a parallel region written inside that body
is
reachable from the kernel only through the runtime call. `AAKernelInfo`
could not
see it: it recorded an unknown reaching region, and every kernel using
those
functions got a worker state machine whose only option was an indirect
call to
whatever it was handed.
Describe each function's callback argument in `OMPKinds.def`, attach
`!callback`
metadata, and fold the callback's `AAKernelInfo` state into the
caller's, so the
state machine can dispatch directly to the regions the body reaches. The
[35 lines not shown]
[NFCI][CIR] Add in 2 missing returns- (#222061)
I discovered these two were missing thanks to a warning diagnostic on a
downstream. It isn't clear why this doesn't cause problems anywhere (we
must just not really use these?), but fix it anyway.
Resolve match_any crash during ranking
This commit resolve avoid crash with "Mismatch in the construct traits!"
inside PARALLEL when ranking competing candidates with construct={parallel} and
extension(match_any).
Add Instruction::user_iterator. (#220391)
Users of an Instruction have a special property: they're guaranteed to
be Instructions themselves. Add a specialized iterator to take advantage
of this property.
See the change to IVDescriptors.cpp for an example of how this
simplifies code.
[OpenMPOpt] Ask the runtime how many of a block's threads can be workers
The custom state machine gates a thread on InitCB < BlockHwSize - WarpSize,
reconstructing the number of worker threads from the block size on the
assumption that the main thread occupies a whole warp above them. The DeviceRTL
already computes that number, in mapping::getMaxTeamThreads(), and its own
generic state machine gates on it in shouldEnterStateMachine(). Export it as
__kmpc_get_max_team_threads(IsSPMD) and call that instead, so the compiler's
state machine and the runtime's agree by construction rather than by arithmetic
that has to be kept in step with the launch geometry.
The entry point is handed the mode rather than reading it back from
mapping::isSPMDMode(), for the same reason shouldEnterStateMachine() takes it as
a parameter: IsSPMDMode lives in shared memory and only the initial thread
writes it, and in generic mode __kmpc_target_init() returns to the workers
without a barrier in between, so that write is not yet theirs to read at this
point. The compiler passes a constant, a custom state machine being built only
for a generic-mode kernel.
[18 lines not shown]
PPC: Replace EnableAIXExtendedAltivecABI with "target-abi" module flag
Continue purging ABI-influencing TargetOptions fields. Eliminate this case
by migrating to a module flag, reusing the generic target-abi module flag
with a new value.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
[lldb][Windows] Translate file descriptors between CRT instances (#217126)
The official LLVM and lldb builds use `LLVM_ENABLE_RPMALLOC`. This
changes the default CRT allocator to rpmalloc for performance reasons.
In doing so, it also changes the CRT linkage from dynamic (`/MD`) to
static (`/MT`).
Since the CRT is the one managing file descriptors on Windows, its
universe is now scoped to a module. For lldb, this means we have three
fd-spaces: the driver (lldb/lldb-dap), liblldb, and Python.
We usually pass files around as file descriptors. This breaks when we do
it between modules.
Fortunately, the C runtime provides us with helpers to translate between
the process scoped HANDLEs and file descriptors. This way, we can
allocate an fd for a handle passed across modules. For Python, there's
the [`msvcrt`](https://docs.python.org/3/library/msvcrt.html) library we
can use to translate.
Fixes #216679.
PPC: Read the ELF ABI from the "target-abi" module flag
Resolve the ELFv2 ABI from the effective ABI name module flag,
rather than strictly relying on the -target-abi flag.
Also start emitting "target-abi" for PPC from clang.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
[AMDGPU] Update no-modifier operand tests for the dropped align diagnostic
The no-modifier reg-or-inline operands routed through the HwMode
predicate now report a misaligned tuple as a plain invalid operand,
matching the diagnostic dropped earlier in the stack.
[AMDGPU] Route no-modifier reg-or-inline AsmParser operands through HwMode predicate
Convert the reg-or-inline operands with no modifiers (MFMA VGPR/AGPR
sources, VCSrc, v_pk_mov_b32, VOP scalar f64) from the fixed-class
isRegOrInlineNoMods to the HwMode-aware isRegOrInlineNoModsByHwMode, so an
odd-aligned tuple is rejected at the offending operand column instead of by
the validateVGPRAlign catch-all.
Co-Authored-By: Claude <noreply at anthropic.com>
[AMDGPU] Drop the misaligned VGPR-tuple AsmParser diagnostic
The alignment-aware matchers already reject a misaligned tuple, so a
misaligned operand now fails as a plain invalid operand. Keeping the
dedicated "vgpr tuples must be 64 bit aligned" message only for that
case is not worth the extra match-error ranking, the per-operand
diagnostic, and getUnalignedEquivalentRC, so remove all of it.
[AMDGPU] Make custom AsmParser matchers alignment aware
Currently custom matchers accept registers belonging to unaligned classes,
leaving the alignment check and its diagnostic to validateVGPRAlign. The problem
is that validateVGPRAlign does not account for the operand register class, which
may have a different alignment requirement on mixed-alignment targets.
The fix is to make a custom matcher resolve the operand's _AlignTarget class via
HwMode and use that resolved class to accept a register. However, doing so alone
would reject a misaligned register with a generic "invalid operand for
instruction" diagnostic, so extra infrastructure conveys the alignment diagnostic
instead: on a class miss, diagnoseRegAlign re-checks the register against the same
class with alignment relaxed (getUnalignedEquivalentRC, new in AMDGPUBaseInfo);
if it fits, the only problem is alignment, so it records
OperandMatchError::VGPRAlignMismatch on the operand. matchAndEmitInstruction
selects that reason and prints the alignment error, now at the offending operand
column instead of column 1.
This commit converts the input-mods and DP-ALU DPP matchers. The no-modifier
[4 lines not shown]
[AMDGPU] Factor the AsmParser match-specificity comparison into a helper, NFC
Extract the "keep the most specific match status" comparison in
matchAndEmitInstruction into an atLeastAsSpecific() lambda ranking
Match_MnemonicFail < Match_InvalidOperand < Match_MissingFeature. No
functional change.
CodeGen: Remove TargetOptions::HonorSignDependentRoundingFPMathOption (#222027)
This option was only settable through the hidden -enable-sign-dependent-
rounding-fp-math flag and was never set by the in-tree frontends. Its
documentation describes honoring a dynamically-changeable rounding mode,
which is what strictfp is for; this relic predates any design for FP
mode controls.
Replace the one ARM consumer with strictfp checks, and remove the
predicate from the patterns which checked it. There were also no tests
for the pattern, so add those.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
[AMDGPU] Add AsmParser tests for misaligned VGPR tuples in custom-predicate operands (#221986)
MFMA VGPR sources, DP-ALU DPP, v_pk_mov_b32 and VOPD3 f64 take VGPR tuple
operands validated by custom AsmParser predicates. Odd-aligned tuples are
currently only caught late by validateVGPRAlign, so the error points at the
whole instruction (column 1). A follow-up moves the diagnostic to the
offending operand.
[MachineFunction] add --print-enabled-features
In clang we have --print-enabled-extensions which will print the
AArch64 extensions enabled for a given TU. However, sometimes it is
useful to be able to print out the actual subtarget features for each
function, for debugging/testing purposes. Add a hidden flag for that.
