The new LEGALAVL node annotates that the AVL refers to packs of 64bit.
We use a two-stage lowering approach with LEGALAVL:
First, standard SDNodes are translated into illegal VVP layer nodes.
Regardless of source (VP or standard), all VVP nodes have a mask and AVL
parameter. The AVL parameter refers to the element position (just as in
VP intrinsics).
Second, we legalize the AVL usage in VVP layer nodes. If the element
size is < 64bit, the EVL parameter has to be adjusted to refer to packs
of 64bits. We wrap the legalized AVL in a LEGALAVL node to track this.
Reviewed By: kaz7
Differential Revision: https://reviews.llvm.org/D118321
This reverts commit ef82063207.
- It conflicts with the existing llvm::size in STLExtras, which will now
never be called.
- Calling it without llvm:: breaks C++17 compat
Packed-mode broadcast of f32/i32 requires the subregister to be
replicated to the full I64 register prior. Add repl_i32 and repl_f32 to
faciliate this.
Reviewed By: kaz7
Differential Revision: https://reviews.llvm.org/D117878
VECustomDAG's functions simplify emitting VE custom ISD nodes. The class
is just a stub now. We add more functions, in particular for the
VP->VVP->VE lowering, to VECustomDAG as we build up vector isel.
Reviewed By: kaz7
Differential Revision: https://reviews.llvm.org/D116103
Extend the VE binaryop vector isel patterns to use passthru when the
result of a SDNode is used in a vector select or merge.
Reviewed By: kaz7
Differential Revision: https://reviews.llvm.org/D117495
Use the `VMRG` for all three operations for now. `vp_select` will be
used in passthru patterns.
Reviewed By: kaz7
Differential Revision: https://reviews.llvm.org/D117206
This reverts commit fd4808887e.
This patch causes gcc to issue a lot of warnings like:
warning: base class ‘class llvm::MCParsedAsmOperand’ should be
explicitly initialized in the copy constructor [-Wextra]
Depends on D115940 for the `Binary_rv_vr_vv` pattern class op isel
fragment used for divisions.
Reviewed By: kaz7
Differential Revision: https://reviews.llvm.org/D116035
Change to use Ctx.reportError() instead of llvm_unreachable for
better error handling. Also correct evaluateAsRelocatableImpl().
Reviewed By: simoll
Differential Revision: https://reviews.llvm.org/D115251
Change to use R_VE_SREL32 for relative branch instructions instead of
R_VE_PC_LO32 in order to check ranges of relative branch isntructions
at link time correctly.
Reviewed By: simoll
Differential Revision: https://reviews.llvm.org/D115097
There is custom expansion code for packed VFMK Pseudos in the VE
backend. This code erased the Pseudo without telling
ExpandPostRAPseudos about it, causing the generic expansion function to
access the erased Pseudo. This bug triggered in the
test/CodeGen/VE/VELIntrinsics/vfmk.ll test with asan-enabled builds.
Detected by:
sanitizer-x86_64-linux-fast
(https://lab.llvm.org/buildbot/#/builders/5/builds/15393)
First call getOperand, then erase the MachineInstr. Not the other way
round.
Expected to fix test/CodeGen/VE/VELIntrinsics/lvm.ll
Detected by asan buildbot:
sanitizer-x86_64-linux-fast
(https://lab.llvm.org/buildbot/#/builders/5/builds/15384)
TableGen has started warning about unused template parameters in the isel patterns. Remove those.
Reviewed By: kaz7
Differential Revision: https://reviews.llvm.org/D113675
VE integrated asm has been the default in Clang. Also use the default setting for integrated asm in the backend.
Reviewed By: kaz7
Differential Revision: https://reviews.llvm.org/D113384
This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.
This allows us to ensure that Support doesn't have includes from MC/*.
Differential Revision: https://reviews.llvm.org/D111454
On some architectures such as Arm and X86 the encoding for a nop may
change depending on the subtarget in operation at the time of
encoding. This change replaces the per module MCSubtargetInfo retained
by the targets AsmBackend in favour of passing through the local
MCSubtargetInfo in operation at the time.
On Arm using the architectural NOP instruction can have a performance
benefit on some implementations.
For Arm I've deleted the copy of the AsmBackend's MCSubtargetInfo to
limit the chances of this causing problems in the future. I've not
done this for other targets such as X86 as there is more frequent use
of the MCSubtargetInfo and it looks to be for stable properties that
we would not expect to vary per function.
This change required threading STI through MCNopsFragment and
MCBoundaryAlignFragment.
I've attempted to take into account the in tree experimental backends.
Differential Revision: https://reviews.llvm.org/D45962
VE's linker, /opt/nec/ve/bin/nld, doesn't implement relative lookup table.
The relative lookup table is introduced by https://reviews.llvm.org/D94355,
but we need to disable it at the moment.
Reviewed By: simoll
Differential Revision: https://reviews.llvm.org/D106224
Currently needsStackRealignment returns false if canRealignStack returns false.
This means that the behavior of needsStackRealignment does not correspond to
it's name and description; a function might need stack realignment, but if it
is not possible then this function returns false. Furthermore,
needsStackRealignment is not virtual and therefore some backends have made use
of canRealignStack to indicate whether a function needs stack realignment.
This patch attempts to clarify the situation by separating them and introducing
new names:
- shouldRealignStack - true if there is any reason the stack should be
realigned
- canRealignStack - true if we are still able to realign the stack (e.g. we
can still reserve/have reserved a frame pointer)
- hasStackRealignment = shouldRealignStack && canRealignStack (not target
customisable)
Targets can now override shouldRealignStack to indicate that stack realignment
is required.
This change will make it easier in a future change to handle the case where we
need to realign the stack but can't do so (for example when the register
allocator creates an aligned spill after the frame pointer has been
eliminated).
Differential Revision: https://reviews.llvm.org/D98716
Change-Id: Ib9a4d21728bf9d08a545b4365418d3ffe1af4d87
This patch changes the interface to take a RegisterKind, to indicate
whether the register bitwidth of a scalar register, fixed-width vector
register, or scalable vector register must be returned.
Reviewed By: paulwalker-arm
Differential Revision: https://reviews.llvm.org/D98874
Simon Moll