[X86] support reserve r8~r15 on X86_64 (#180242)
Which is under discussion in
https://github.com/llvm/llvm-project/issues/179036
Add new options -ffixed_r{8-15} for clang X86 target, like option
"-ffixed_x" for RISCV/AArch64 target.
Also, add target-feature +reserve-r{8-15} for the X86 backend.
The registers which are specified reserved will not be used in
RegAlloc/CalleeSave. Then the reserved registers can be maintained by
user. It will be useful for the runtime/interpreter implementation.
Other registers are used in specific instructions or mechanism, so they
can't be reserved.
[Clang] Permit floating point and pointer values in most atomic ops (#183843)
Summary:
We already support floating point arguments for the standard atomic
functions. LLVM supports these in most cases as well. This PR unifies
the handling and allows this in the cases that the LLVM IR supports.
[lldb] Remove Debugger::{FindTargetWithProcessID, FindTargetWithProcess} (#184446)
In #184259, Jim noticed that Debugger::FindTargetWithProcess and
Debugger::FindTargetWithProcessID are rather poorly designed APIs as
tehy allow code running in one Debugger to mess with Targets from
another Debugger. The only use is Process::SetProcessExitStatus which
isn't actually used.
[lldb] AArch64 register 33 is not cpsr (#183860)
I have an unwind failure where the eh_frame for a
trap handler states that the caller's return address is in eh_frame
register 33, which lldb treats as cpsr.
https://github.com/ARM-software/abi-aa/blob/main/aadwarf64/aadwarf64.rst#dwarf-register-names
Register 33 is ELR_mode, which isn't defined as a register in any of the
AArch64 register definition files in lldb today, so I'm not adding it to
the header files.
rdar://170602999
[lldb] Fix the GoogleTest teardown in the DAP unit tests (#184262)
Some of the DAP tests define a static method named `TeatUpTestSuite`
which is calling `SBDebugger::Terminate`. Besides the typo, the correct
method is `TearDownTestSuite`, which GoogleTest calls after running the
last test in the test suite.
When addressing this, I realized that currently you can't really call
Initialize and Terminate multiple times in the same process. This
depends on:
- https://github.com/llvm/llvm-project/pull/184259
- https://github.com/llvm/llvm-project/pull/184261
[AMDGPU] Add suffix _d4 to tensor load/store with 4 groups D#, NFC (#184176)
Rename TENSOR_LOAD_TO_LDS to TENSOR_LOAD_TO_LDS_d4;
Rename TENSOR_STORE_FROM_LDS to TENSOR_STORE_FROM_LDS_d4;
Also rename function names in a couple of tests to reflect this change.
fixup! Move code to `AArch64ExpandPseudoInsts` and `getTgtMemIntrinsic`
Move code to `AArch64ExpandPseudoInsts` and `getTgtMemIntrinsic`
and use tablegen pattern for intrinsic, plus other small review changes.
[AArch64][clang][llvm] Add ACLE `stshh` atomic store builtin
Add `__arm_atomic_store_with_stshh` implementation as defined
in the ACLE. Validate that the arguments passed are correct, and
lower it to the stshh intrinsic plus an atomic store with the
allowed orderings.
Gate this on FEAT_PCDPHINT so that availability matches
hardware support for the `STSHH` instruction. Use an i64
immediate and side-effect modeling to satisfy tablegen and decoding.
[CIR] Split cir.binop into separate per-operation binary ops (#184227)
Replace the single `cir.binop` operation (dispatched via a `BinOpKind`
enum) with nine distinct ops — `cir.add`, `cir.sub`, `cir.mul`,
`cir.div`, `cir.rem`, `cir.and`, `cir.or`, `cir.xor`, and `cir.max` —
each with precise type constraints and only the attributes it needs
(nsw/nuw/sat on add/sub via `BinaryOverflowOp`).
A new `BinaryOpInterface` provides uniform `getLhs`/`getRhs`/`getResult`
access for passes and analyses.
The monolithic switch-based CIRToLLVMBinOpLowering is replaced by per-op
patterns generated through the existing CIRLowering.inc TableGen
infrastructure, with shared dispatch factored into two helpers:
`lowerSaturatableArithOp` for add/sub and `lowerIntFPBinaryOp` for
div/rem.
[lldb] Remove call_once wrappers around PluginManager::RegisterPlugin (#184273)
Remove call_once wrappers around PluginManager::RegisterPlugin. Plugins
can be registered and unregistered in Initialize and Terminate
respectively. In its current state, after having called Terminate, a
plugin can never be re-initialized.