If the scalar integer selection sources are freely transferable to the
FPU, then splat to create an allbits select condition and create a
vector select instead
This patch adds initial support for AMD Zen 6 architecture (znver6):
- Added znver6 CPU target recognition in Clang and LLVM
- Updated compiler-rt CPU model detection for znver6
- Added znver6 to target parser and host CPU detection
- Added znver6 to various optimizer tests
znver6 features: FP16, AVXVNNIINT8, AVXNECONVERT, AVXIFMA (without BMM).
The llvm.cond.loop intrinsic is semantically equivalent to a conditional
branch conditioned on ``pred`` to a basic block consisting only of an
unconditional branch to itself. Unlike such a branch, it is guaranteed
to use specific instructions. This allows an interrupt handler or
other introspection mechanism to straightforwardly detect whether
the program is currently spinning in the infinite loop and possibly
terminate the program if so. The intent is that this intrinsic may
be used as a more efficient alternative to a conditional branch to
a call to ``llvm.trap`` in circumstances where the loop detection
is guaranteed to be present. This construct has been experimentally
determined to be executed more efficiently (when the branch is not taken)
than a conditional branch to a trap instruction on AMD and older Intel
microarchitectures, and is also more code size efficient by avoiding the
need to emit a trap instruction and possibly a long branch instruction.
On i386 and x86_64, the infinite loop is guaranteed to consist of a short
conditional branch instruction that branches to itself. Specifically,
the first byte of the instruction will be between 0x70 and 0x7F, and
the second byte will be 0xFE.
Part of this RFC:
https://discourse.llvm.org/t/rfc-optimizing-conditional-traps/89456
Reviewers: arsenm, RKSimon, fmayer, vitalybuka
Pull Request: https://github.com/llvm/llvm-project/pull/177686
combineVectorSizedSetCCEquality attempts to convert equality comparisons
of larger-than-legal scalar integers to PTEST/PMOVMSKB vector
comparisons.
However, combineSetCC has a number of other folds with more complex
icmp_eq/ne patterns that work with big integers (including bit test and
reduction patterns) that don't get a change to match as
combineVectorSizedSetCCEquality is run first, and the other folds are
then more difficult to match from PTEST/PMOVMSKB nodes.
This patch moves the combineVectorSizedSetCCEquality fold later to give
other icmp_eq/ne folds a chance to run first.
Port x86-cleanup-local-dynamic-tls to the new pass manager.
I moved LDTLSCleanup to a new
llvm/lib/Target/X86/X86CleanupLocalDynamicTLS.cpp file and renamed it to
X86CleanupLocalDynamicTLSPass. Then I renamed the legacy pass, and
adding a NewPM wrapper around the impl.
No test coverage added for now as there are no MIR->MIR tests exercising
this pass and we do not have enough ported to run any end to end tests.
As noted on #174761 - we need to ensure custom lowering to logic/add/sub
ops might actually occur before assuming the node will have been on the
vector unit
If a EXPAND node mask is just the lowest bits, then we can replace it
with a more general SELECT node, which can be cheaper and potentially
allow predication.
Fixes#179008
The vgf2p8affineqb instruction performs an affine transformation on each
byte and then XORs the result with an 8-bit immediate operand. When this
instruction is followed by a standalone XOR with a splatted constant,
LLVM currently generates extra instructions instead of folding the
constant into the instruction's immediate.
This PR adds a DAG combine optimization that detects the pattern
vgf2p8affineqb(x, m, imm8) ^ C where C is a splatted 8-bit constant and
transforms it to vgf2p8affineqb(x, m, imm8 ^ C), eliminating the
unnecessary XOR instruction.
- The optimization runs during the combine phase after type legalization
- Handles XOR with the constant on either side (commutative)
- Only applies when the GFNI instruction has a single use to avoid
de-optimization
- Validates that the XOR operand is a splatted 8-bit constant before
folding
- Includes test coverage for positive cases and negative cases
(multi-use, non-splat constant, variable XOR)
CTTZ can be lowered using GF2P8AFFINEQB if we isolate the lowest set bit
(or is zero) and then use GF2P8AFFINEQB to perform a look up
With CTTZ, CTLZ can be lowered as CTTZ(BITREVERSE())
As discussed on #110308
`constrainSelectedInstRegOperands` always returns `true`; so it can be
safely transformed to return `void` instead.
A follow-up patch should update `MachineInstrBuilder::constrainAllUses`.
Inspired by the hack to #174761 - move the custom operation handling
inside mayFoldIntoVector where we can more accurately predict ops that
can be moved to the vector unit
106549a436/src/pnpbios.c (L70)
has code that looks like
```
extern int X;
unsigned f(void) { return (unsigned)&X - 0xf0000; }
```
which compiles (-O1 or above, -fno-pic) to
```
.code16
leal X-983040, %eax # R_386_16 relocation, [-65535,65535]
```
in 16-bit mode. This is rejected by both GNU Assembler and LLVM
integrated assembler (after #176827).
Restrict offset folding in 16-bit mode to the range [-65535, 65535].
This patch adds post legalize combiner for X86 Target.
Use case for OptNone Combine: I am curious about OptNone usecase,
specifically when we are using -On on command line and no opt on
specific function.
The PUSH2/POP2/PPX instructions for APX require updates to the Microsoft
Windows OS x64 calling convention documented at
https://learn.microsoft.com/en-us/cpp/build/exception-handling-x64?view=msvc-170
due to lack of suitable unwinder opcodes that can support APX
PUSH2/POP2/PPX.
The PR request disables this support by default for code robustness;
workloads that choose to explicitly enable this support can change the
default behavior by explicitly specifying the flag options that enable
this support e.g. for experimentation or code paths that do not need
unwinder support.
While tuning ProcessBLENDWToBLENDD
07ec2fa144/llvm/lib/Target/X86/X86FixupInstTuning.cpp (L262)
we creating mask from `getImm()` which returns 64bit int and APInt
accept 64 bit int.
```
APInt MaskW =
APInt(8, MI.getOperand(NumOperands - 1).getImm(), /*IsSigned=*/false);
```
It fails with MIR for BLENDW instruction that requires8 bit mask 0xAA
from 64 bit Imm.
```
renamable $xmm2 = VPBLENDWrri renamable $xmm1, killed renamable $xmm2, -86
```
APInt construction complains since higher bits of are also set for
transformations where mask bits are set (results in negative values).
07ec2fa144/llvm/include/llvm/ADT/APInt.h (L125)
This patch uses implictTruncate from APInt constructor to get around.
other approach could have been using direct mask(same effect as implicit
truncate) `AND` with Imm or use signed version (not applicable since
mask).
This case was generate using bisect so most of test excercises, i tried
with VPBLEND generating IR refuse to generate mask in range 0b10101010,
so patch lacks test.
There's no benefit to letting vperm2x128 handle the fold in an unary
shuffle and llvm-mca assumes there's an extra register dependency, which
confuses analysis.
Fixes#178632
Avoid situations where SimplifyDemandedVectorElts / shuffle combining
keeps messing with the zero masks of inner insertps - usually this is
benign but if they share operands it can cause infinite loops
Fixes#178538
When the immediate is 0x44, VPERMQ/VPERMPD duplicates the lower 128-bit
lane to both lanes. This is equivalent to inserting the lower 128-bits
into the upper 128-bit position, which VINSERTI128/VINSERTF128 can
potentially do more efficiently on some targets.
This patch enables X86FixupInstTuning to convert:
VPERMQ ymm, ymm, 0x44 -> VINSERTI128 ymm, ymm, xmm, 1
VPERMPD ymm, ymm, 0x44 -> VINSERTF128 ymm, ymm, xmm, 1
Resolves#159410
This commit introduces the VectorInstrContext (VIC) infrastructure to
improve cost estimates for insert/extracts based on the context
instruction in which the insert/extract is used.
This is similar to CastContextHint, and allows providing context on how
the insert/extract is going to be used before creating IR. This is
useful in the LoopVectorizer, where costs need to estimated before
creating IR.
The new hint currently only replaces an existing check in AArch64,
but new uses will be introduced in follow-ups, including
https://github.com/llvm/llvm-project/pull/177201.
PR: https://github.com/llvm/llvm-project/pull/175982
Peek through free scalar_to_vector/extract_vector_elt pairs (of the same
vector width) that might still persist (ideally a better topological
sorting would have removed these already....)
When inserting elements into <vscale x N x i64> scalable vectors, the X86 backend now returns InstructionCost::getInvalid() instead of panicking.
Fixes#176823
