Initialize targets before creating a LibraryOptionsContext. NFC (#233041)
Initialize the targets to register their library options, before parsing
command line arguments.
This prepares for removing the T::Global fallback in
`LibraryOptionsContext::get<T>()`.
(The -mtriple change of llvm-split was originally added for
AMDGPU --lto-partitions #83128)
[LTO,lld] Set -mllvm library options in the LTO context. NFC (#233026)
Follow-up to #231407: move tools off cl::ParseCommandLineOptions, which
sets the libraries' `XXXOptions::Global`, to
`cl::parseCommandLineOptions(LibraryOptionsContext &, ...)`.
lto::Config::LibraryOptions replays into every LLVMContext that LTO
creates: the regular LTO context, each ThinLTO backend, and split code
generation.
This prepares for removing the T::Global fallback in
LibraryOptionsContext::get<T>().
LLM-aided
[FuzzMutate] Parse fuzzer options into a context. NFC (#233035)
Move tools off cl::ParseCommandLineOptions, which sets the libraries'
`XXXOptions::Global`, to
`cl::parseCommandLineOptions(LibraryOptionsContext &, ...)`.
Create LibraryOptionsContext after initializing the targets (which may
register library options).
This prepares for removing the T::Global fallback in
`LibraryOptionsContext::get<T>()`.
[LoongArch] Add shuffle and vector element cost hooks
The default BasicTTI costs a broadcast of <2 x double> as 3 and a
single-source permutation of 32/64-bit elements as up to 4, although
LSX/LASX need one [x]vreplvei/[x]vreplgr2vr/xvreplve0 or vshuf4i
instruction. Extracting element 0 of an FP vector is free since it is
the aliased FPR.
These overestimates made the SLP vectorizer reject the {x, y} lanes of
the rustc-perf nbody force loop, which needs two scalar splats per
iteration. With them the loop splits its divisions between the vector and
scalar dividers: 21.5 -> 16.0 cycles per pair on LA664.
rustc-perf nbody on LA664: instructions -11.1%, cycles -13.5%.
[ValueTracking] Infer x != y from (x - y) pred C when 0 pred C is false (#225200)
Generalize the `(a - b) == NonZero -> a != b` implication (#159792) to
`(a - b) pred C -> a != b` whenever `0 pred C` is false, and let
`findValuesAffectedByCondition` register the operands of `sub` in
ordered comparisons with a constant, so that assumes and dominating
conditions can use it.
Alive2: https://alive2.llvm.org/ce/z/r_x-R-
Fixes #223345.
Assisted-by: Claude
MC: Remove MCAsmInfo::ExceptionsType
The exception model now comes from the module, and the MCAsmInfo
predicates that depend on it take the model as a parameter. The
target's default model is still available from
Triple::getDefaultExceptionHandling.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
WebAssembly: Use reportFatalUsageError for eh option errors
Avoid using the deprecated report_fatal_error, and add missing
error test coverage.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
CodeGen: Remove TargetOptions::ExceptionModel
The exception model now comes only from the "exception-model" module
flag. Remove the TargetOptions field and its copy into MCAsmInfo, so
MCAsmInfo only knows the target's default model.
The WebAssembly model checks move from the TargetMachine constructor
into the Emscripten EH/SjLj lowering pass. Clang relied on the backend
to reject non-wasm models for wasm targets, so it now rejects them
itself.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
CodeGen: Read the exception model from the module flag
Module::getExceptionModel() now falls back to the triple's default
model instead of falling back to the TargetMachine.
The pass pipeline is built before the module is known, so schedule each
EH preparation pass when the target supports a model, and let the pass
check the module's model. Add TargetMachine::supportsExceptionModel so
the pass config can skip definitely irrelevant passes. SjLjEHPrepare is
now scheduled on every target with exception handling, and WinEHPrepare
only on COFF and Wasm targets. WinEHPrepare and WasmEHPrepare are
scheduled for Wasm by the base pass configs, replacing the WebAssembly
override.
This is almost the last step towards removing TargetOptions::ExceptionModel.
Co-authored-by: Claude Opus <noreply at anthropic.com>
AArch64: Move the Windows trap after noreturn calls into the AsmPrinter (#232358)
With Windows unwind info, the unwinder finds the function or funclet
for a frame from its return address, so a call must not be the last
instruction of one.
This was hackily handled by overwriting TrapUnreachable in the
TargetMachine constructor which inserts traps after every
unreachable. X86 handles the same problem by padding calls in the
AsmPrinter, so do the same here: emit a trap only after a noreturn
call that would end a function or funclet. This addresses the FIXME
about eliding the trap when the next instruction is in the same
region, so noreturn calls in the middle of a function no longer get a
trap.
This removes one of the last obstacles to removing ExceptionModel from
TargetOptions.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[OpenMP][flang] Score unknown context selector properties by selector
Flang records an unknown property such as kind(bogus) or vendor(bogus)
as TraitProperty::invalid, which belongs to no selector. Under
match_any or match_none, where such a variant can still be selected,
the property therefore lost its selector's weight: kind(bogus) added
nothing, while an unmatched kind(gpu) adds 2^l, where l is the number of
constructs in the context. A score on a selector that mixes known and
unknown properties was also added twice, once for the known property and
once for invalid, and unknown properties in different selectors shared
a single score.
Add VariantMatchInfo::addUnknownTrait, which keeps the property
unmatched and records its selector and score, and score that selector
like any other. Use it in Flang. Clang drops unknown properties while
parsing and is unaffected.
Fixes: https://github.com/llvm/llvm-project/issues/233029
Assisted-by: GitHub Copilot (Claude Opus 5.5)
[clang][Driver] Use the Windows ARM64 defaults for aarch64-unknown-uefi
Match the Windows ARM64 driver defaults for aarch64-unknown-uefi, which
follows the same ABI:
* char is signed, so do not pass -fno-signed-char,
* the frame chain must stay valid even when frame pointers are omitted,
so -fomit-frame-pointer yields -mframe-pointer=reserved rather than
none, as the backend reserves the frame pointer for UEFI as well.
Assisted-by: Claude
[clang] Add aarch64-unknown-uefi target
Add the aarch64-unknown-uefi target to clang, building on the backend
support added in the preceding patches. Like x86_64-unknown-uefi it
follows the Microsoft ABI conventions, matching the Windows ARM64 target
which is the only way EFI applications for AArch64 can be built with
Clang/LLVM today:
* add UEFIAArch64TargetInfo: LLP64 types, Microsoft C++ ABI, char*
based va_list and the Win64 calling convention kind,
* use the Windows AArch64 ABI info in CodeGen for UEFI,
* accept aarch64 for *-uefi triples in the driver.
The UEFI toolchain already handles the linker invocation (lld-link with
/subsystem:efi_application), so no further driver changes are needed.
Assisted-by: Claude
[AArch64] Apply the Windows SEH and CRT codegen constraints to UEFI
aarch64-unknown-uefi uses SEH unwind information and has no C runtime
library, so the remaining Windows specific codegen decisions that follow
from this apply to it too:
* do not align loops or basic blocks, since SEH unwind info generation
needs the exact function layout before alignment padding is inserted,
* sign return addresses with the B key by default and reject A key
signing, matching the pac_sign_lr unwind code used by the unwinder,
* do not lower wide shifts to libcalls at -Oz, as those helpers are not
available.
The corresponding Windows tests gain aarch64-unknown-uefi run lines and
the LLVM release notes announce the new target, which completes the
backend side of aarch64-unknown-uefi support.
Assisted-by: Claude
[AArch64] Classify global references on UEFI like Windows COFF
Apply the Windows COFF rules for global references to
aarch64-unknown-uefi, which produces the same PE/COFF images:
* classify dllimport and non-dso-local globals with MO_DLLIMPORT /
MO_COFFSTUB, so extern_weak symbols are referenced through a stub that
can be resolved to zero by the linker,
* keep the existing SelectionDAG, FastISel and GlobalISel handling of
calls and tail calls to extern_weak functions in sync with that,
* default to the PIC relocation model, so jump tables and other
references stay position independent in relocatable PE images,
* lower ifuncs on UEFI as COFF has no support for them.
The extern weak and jump table tests gain aarch64-unknown-uefi run lines.
Assisted-by: Claude
[AArch64] Use Windows style stack probing on UEFI
Like Windows, and like x86_64-unknown-uefi already does, probe large
stack frames and dynamic allocas through the __chkstk helper on
aarch64-unknown-uefi instead of the inline stack probe loop:
* make the __chkstk STACK_PROBE libcall available for AArch64 UEFI,
* select the Windows stack probe paths in frame lowering,
LowerDYNAMIC_STACKALLOC and the SME state buffer allocation, honouring
the "no-stack-arg-probe" attribute as on Windows,
* fall back from GlobalISel to SelectionDAG for dynamic allocas, as is
done for Windows, since the IRTranslator does not implement the probing.
The existing chkstk and alloca tests gain aarch64-unknown-uefi run lines.
Assisted-by: Claude
[AArch64] Reserve x18 as the platform register on UEFI
Both the Windows ARM64 ABI, which UEFI follows, and the firmware
ecosystem (EDK2 builds AArch64 with -ffixed-x18) treat x18 as a reserved
platform register. Reserve it by default for aarch64-unknown-uefi, as is
already done for Windows, Darwin, Android, Fuchsia and OHOS.
Assisted-by: Claude
[AArch64] Use the Windows ARM64 ABI for UEFI targets
UEFI follows the Windows ARM64 procedure call standard (the UEFI
specification defines AArch64 EFI images in terms of the Microsoft
toolchain, and that is how EDK2 and clang-built firmware are linked
today), and x86_64-unknown-uefi likewise uses the Win64 ABI. Introduce
AArch64Subtarget::isTargetUEFI() and isTargetWindowsOrUEFI() and use the
latter for the core ABI decisions that currently key off
isTargetWindows():
* the Win64 calling convention for C/Fast/Swift calls, including the
Windows variadic convention which homes all argument registers and
passes floating point variadic arguments in GPRs,
* the char* based va_list (va_copy size and getVaListSizeInBits),
* the Windows callee saved register list and the matching frame record
pairing rules in AArch64FrameLowering, which have to agree so that the
SEH save_regp/save_fplr unwind codes describe consecutive registers,
* the requirement that the frame chain stays valid in every function.
[11 lines not shown]
[AArch64] Use the Microsoft COFF MCAsmInfo for UEFI targets
UEFI follows the MSVC toolchain conventions and lld-link is used to
produce the PE/COFF images, so aarch64-unknown-uefi should use the
Microsoft COFF MCAsmInfo like the X86 backend already does for
x86_64-unknown-uefi, rather than the GNU (MinGW) flavour it currently
gets by virtue of being a non-MSVC COFF triple. This enables associative
COMDATs and COMDAT constant pool entries (which AsmPrinter already
expects for UEFI, see GetCPISymbol).
Also relax the AArch64MCInstLower assertion that only Windows COFF
targets exist.
This is the first in a series of patches adding aarch64-unknown-uefi
support to the AArch64 backend and clang.
Assisted-by: Claude
[flang][OpenMP] Set the target in bbc's semantics context
bbc created a target machine but never passed its triple and features to
the semantics context. Without a target triple, semantics treats device
and implementation context selectors as possibly matching, so it
checked METADIRECTIVE replacements that can never be selected for the
target. For example, bbc reported a COLLAPSE error for the SIMD
replacement of when(device={arch(nvptx64)}: simd collapse(2)) on
x86-64, while flang accepts it.
Set the semantics target triple and features from the target machine, as
the flang driver does.
Fixes https://github.com/llvm/llvm-project/issues/233027.
Assisted-by: GitHub Copilot (Claude Opus 5.5)
[flang] Parse -mllvm library options into a context. NFC (#233021)
Follow-up to #231407: move flang -fc1 off cl::ParseCommandLineOptions,
which sets the libraries' `XXXOptions::Global`, to
`cl::parseCommandLineOptions(LibraryOptionsContext &, ...)`.
This prepares for removing the T::Global fallback in
`LibraryOptionsContext::get<T>()`.
The context lives in CompilerInstance like clang -cc1.