This change adds basic `MCInst` verification (checks the number of
operands) and fixes detected bugs.
* `RFE*` instructions have only one operand, but `DecodeRFEInstruction`
added two.
* `DecodeMVEModImmInstruction` and `DecodeMVEVCMP` added a `vpred`
operand, but this is what `AddThumbPredicate` normally does. This
resulted in an extra `vpred` operand.
* `DecodeMVEVADCInstruction` added an extra immediate operand.
* `getARMInstruction` added a `pred` operand to instructions that don't
have one (via `DecodePredicateOperand`).
* `AddThumb1SBit` appended an extra register operand to instructions
that don't modify CPSR (such as `tBL`).
* Instructions in `NEONDup` namespace have `pred` operand that the
generated code successfully decodes. The operand was added once again by
`getARMInstruction`/`getThumbInstruction` via `AddThumbPredicate`.
Functional changes extracted from #156540.
Add `bits<0>` fields to instructions using the ZTR/MPR/MPR8 register
classes. These register classes contain only one register, and it is
not encoded in the instruction. This way, the generated decoder can
completely decode instructions without having to perform a post-decoding
pass to insert missing operands.
Some immediate operands are also not encoded and have only one possible
value "zero". Use this trick for them, too.
Finally, remove `-ignore-non-decodable-operands` option from
`llvm-tblgen` invocation to ensure that non-decodable operands do not
appear in the future.
Rather then defining these tags in each object file that requires them
we can can declare them as undefined and require that they defined
externally in, for example, compiler-rt or libcxxabi.
These instructions have one already narrow operand. Previously, we
pretended like this operand was a supported extension.
This could cause problems when we called getOrCreateExtendedOp on this
narrow operand when creating the the VWADD_VL. If the narrow operand
happened to be an extend of the opposite type, we would peek through it
and then rebuild it with the wrong extension type. So (vwadd_w_vl (i32
(sext X)), (i16 (zext Y))) would become (vwadd_vl (i16 (sext X)), (i16
(sext Y))).
To prevent this, we ignore the operand instead and pass std::nullopt for
SupportsExt to getOrCreateExtendedOp so it won't peek through any
extends on the narrow source.
Fixes#159152.
The result type of the vector extend intrinsics generated by the
BUILD_VECTOR lowering code should match how they are actually defined.
Currently the result type is defaulting to the operand type there. This
can conflict with calls to the same intrinsic from other paths.
AIX has "millicode" routines, which are functions loaded at boot time
into fixed addresses in kernel memory. This allows them to be customized
for the processor. The __strlen routine is a millicode implementation;
we use millicode for the strlen function instead of a library call to
improve performance.
In this commit:
(1) Added new pass manager support for `ReachingDefAnalysis`.
(2) Added printer pass.
(3) Make old pass manager use `ReachingDefInfoWrapperPass`
This is a generalization of the LookupPtrRegClass mechanism.
AMDGPU has several use cases for swapping the register class of
instruction operands based on the subtarget, but none of them
really fit into the box of being pointer-like.
The current system requires manual management of an arbitrary integer
ID. For the AMDGPU use case, this would end up being around 40 new
entries to manage.
This just introduces the base infrastructure. I have ports of all
the target specific usage of PointerLikeRegClass ready.
This PR adds a TargetLowering hook, canTransformPtrArithOutOfBounds,
that targets can use to allow transformations to introduce out-of-bounds
pointer arithmetic. It also moves two such transformations from the
AMDGPU-specific DAG combines to the generic DAGCombiner.
This is motivated by target features like AArch64's checked pointer
arithmetic, CPA, which does not tolerate the introduction of
out-of-bounds pointer arithmetic.
There are more places in SIISelLowering.cpp and AMDGPUISelDAGToDAG.cpp
that check for ISD::ADD in a pointer context, but as far as I can tell
those are only relevant for 32-bit pointer arithmetic (like frame
indices/scratch addresses and LDS), for which we don't enable PTRADD
generation yet.
For SWDEV-516125.
Previously asan considers target intrinsics as black boxes, so asan
could not instrument accurate check. This patch make
SmallVector<InterestingMemoryOperand> a member of MemIntrinsicInfo so
that TTI can make targets describe their intrinsic informations to asan.
Note,
1. This patch move InterestingMemoryOperand from Transforms to Analysis.
2. Extend MemIntrinsicInfo by adding a
SmallVector<InterestingMemoryOperand> member.
3. This patch does not support RVV indexed/segment load/store.
The manual legalizeOperands code only need to consider cases that
require full instruction context to know if the operand is legal.
This does not need to handle basic operand register class constraints.
If the original type was i32, type legalization will sign extend
the constant. This prevents it from having a single bit set or clear
so other patterns can't match. If the upper bits aren't used, we
can ignore the sign extension.
Similar for bclri and binvi.
The original patterns for the Xqci select-like instructions used
`select`, and marked that ISD node as legal. This is not the usual way
that `select` is dealt with in the RISC-V backend.
Usually on RISC-V, we expand `select` to `riscv_select_cc` which holds
references to the operands of the comparison and the possible values
depending on the comparison. In retrospect, this is a much better fit
for our instructions, as most of them correspond to specific condition
codes, rather than more generic `select` with a truthy/falsey value.
This PR moves the Xqci select-like patterns to use `riscv_select_cc`
nodes. This applies to the Xqcicm, Xqcics and Xqcicli instruction
patterns.
In order to match the existing codegen, minor additions had to be made
to `translateSetCCForBranch` to ensure that comparisons against specific
immediate values are left in a form that can be matched more closely by
the instructions. This prevents having to insert additional `li`
instructions and use the register forms.
There are a few slight regressions:
- There are sometimes more `mv` instructions than entirely necessary. I
believe these would not be seen with larger examples where the register
allocator has more leeway.
- In some tests where just one of the three extensions is enabled,
codegen falls back to using a branch over a move. With all three
extensions enabled (the configuration we most care about), these are not
seen.
- The generated patterns are very similar to each other - they have
similar complexity (7 or 8) and there are still overlaps. Sometimes the
choice between two instructions can be affected by the order of the
patterns in the tablegen file.
One other change is that Xqcicm instructions are prioritised over Xqcics
instructions where they have identical patterns. This is done because
one of the the Xqcicm instructions is compressible (`qc.mveqi`), while
none of the Xqcics instructions are.
Vector integer division in SiFive7 processes a single bit at a time up
to 4 elements. This patch updates to reflect this behavior.
Co-authored-by: Michael Maitland <michaeltmaitland@gmail.com>
The latency of floating point loads in SiFive7 should be the same as
their integer counterparts.
Co-authored-by: Michael Maitland <michaeltmaitland@gmail.com>
This patch mirrors similar patterns for ISD::ADD. The main difference is
that ISD::ADD is commutative, so that a pattern definition for, e.g.,
(add (mul x, y), z), automatically also handles (add z, (mul x, y)).
ISD::PTRADD is not commutative, so we would need to handle these cases
explicitly. This patch only implements (ptradd z, (op x, y)) patterns,
where the nested operation (shift or multiply) is the offset of the
ptradd (i.e., the right operand), since base pointers that are the
result of a shift or multiply seem less likely.
For SWDEV-516125.
Add new event SCC_WRITE for s_barrier_signal_isfirst and s_barrier_leave,
instructions that write to SCC, counter is KM_CNT.
Also start tracking SCC for reads and writes.
s_barrier_wait on the same barrier guarantees that the SCC write from
s_barrier_signal_isfirst has landed, no need to insert s_wait_kmcnt.
