Use deduction guides instead of helper functions.
The only non-automatic changes have been:
1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*))
2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase.
3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated.
4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that).
Per reviewers' comment, some useless makeArrayRef have been removed in the process.
This is a follow-up to https://reviews.llvm.org/D140896 that introduced
the deduction guides.
Differential Revision: https://reviews.llvm.org/D140955
The patch also adds expandVPCTLZ and expandVPCTTZ to expand vp.ctlz/cttz nodes
and the cost model of vp.ctlz/cttz.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D140370
The patch tries to make more vslidup nodes use tail agnostic. The idea comes
from D125546 authored by Zack Chen.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D140669
isel is now capable of turning the SUB into XOR for shift amounts.
Though it uses NOT instead of XOR with ShiftSize-1.
By using SUB during lowering we enable more DAG combines with
other arithmetic on the shift amount.
Two comparison operations and a logical operation are combined into selection using MIN or MAX and comparison operation.
For optimization to be applied conditions have to be satisfied:
1. In comparison operations has to be the one common operand.
2. Supports only signed and unsigned integers.
3. Comparison has to be the same with respect to common operand.
4. There are no more users of comparison except logic operation.
5. Every combination of comparison and AND, OR are supported.
It will convert
%l0 = %a < %c
%l1 = %b < %c
%res = %l0 or %l1
into
%sel = min(%a, %b)
%res = %sel < %c
It supports several comparison operations (<, <=, >, >=), signed, unsigned values and different order of operands if they do not violate conditions.
Differential Revision: https://reviews.llvm.org/D134277
Similar for sub, or, and xor. These are all operations that have 0
as a neutral value. This is based on a similar tranform in InstCombine.
This allows us to remove some XVentanaCondOps patterns and
some code from DAGCombine for RISCVISD::SELECT_CC.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D140465
There is room for optimization to use tail agnostic vslideup/vslidedown to lower
some vector operations. D125546 is an revision for the kind of optimization.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D140393
Address the inconsistency between FLT_ROUNDS_ and SET_ROUNDING SDAG
node. Rename FLT_ROUNDS_ to GET_ROUNDING and add llvm.get.rounding
intrinsic to replace flt.rounds.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D139507
With D134950, targets get notified when a virtual register is created and/or
cloned. Targets can do the needful with the delegate callback. AMDGPU propagates
the virtual register flags maintained in the target file itself. They are useful
to identify a certain type of machine operands while inserting spill stores and
reloads. Since RegAllocFast spills the physical register itself, there is no way
its virtual register can be mapped back to retrieve the flags. It can be solved
by passing the virtual register as an additional argument. This argument has no
use when the spill interfaces are called during the greedy allocator or even the
PrologEpilogInserter and can pass a null register in such cases.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D138656
If the divisor is repeated at least twice, we will convert the FDIVs to the
calculation of the reciprocal and FMULs.
We perform the transformation only under fast-math mode. FDIVs must have
'arcp' flag.
Differential Revision: https://reviews.llvm.org/D140024
This is a follow up to patch discussion on D139656. As noted there, M2/M4/M8 versions of these instructions don't actually exist, and using them results in overly constrained register allocation.
In that review, we'd talked about moving towards a variant of the instructions which ignored LMUL. I decided to see what happened if we just stopped generating the high LMUL variants, and the results are surprisingly neutral. I only see one minor thing which looks like a real regression among all the churn. I think this is worth doing now to loosen register allocation constraints, and avoid digging our hole around these instructions deeper while thinking about the right model change.
Differential Revision: https://reviews.llvm.org/D140027
The patch also adds expandVPCTPOP in TargetLowering to expand VP_CTPOP nodes.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D139920
This is an alternative patch on a path to D137530.
The basic problem being tackled here is that we need to place a scalar into lane 0 of a vector register before our reduction instructions. Since we only care about lane 0 of the vector, we can use any VL >= 1 provided that the total amount of work performed matches the work performed for a VL=1.
This change does not contain the logic from D137530 to perform the insert at the original VT, and then extract down to LMUL1. That turns out to be a good choice, as discussion in this review has indicated there are issues around LMUL2 and above with our representation of vmv.s.x. We'd also need to be careful with the splat logic for the same reasons.
The only potentially concerning codegen change I spot here is that we stop using a broadcast load (for VL=1) and instead do a scalar load and insert. I think this is probably reasonable; if reviewers disagree, I can investigate using a broadcast load which writes to the undef lanes. If we want to do that, we should do it for VECTOR_INSERT_ELT as well, so that'll end up as it's own patch series.
Differential Revision: https://reviews.llvm.org/D139656
Remove the call to getSExtOrTrunc.
Reduction ISD nodes produce a scalar result and that result is
allowed to be larger than the vector element type due to type
legalization. This is the same rule we allow for EXTRACT_VECTOR_ELT
for the same reason.
We can copy the result type over from the reduction node to
EXTRACT_VECTOR_ELT.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D139757
This doesn't cause any functional change since this is being applied to a insert generated by the same routine. This is mostly about consolidating the logic for vmv.s.x into one place to simplify future changes.
Use the newly introduced helper routine. At the moment, this generates the same code (at this call site!) since LMUL is restricted to LMUL1 or less, and VL is hard coded to 1. In a future patch, I will loosen the second part.
If we're initializing lane 0 of an undef vector, we can optionally write to other lanes of the vector. Doing so may require additional work, so we don't want to e.g. always use a splat. However, since we don't have an immediate form of vmv.s.x it's useful to use a vmv.v.i if the work required is expected to be equal in practice. We restrict this to when LMUL <= 1 to a) prevent doing additional work at higher LMULs, and b) avoid overconstraining the register allocator.
At the moment, the new utility is only used by one case in INSERT_VECTOR_ELT lowering. My expectation is that we will reuse this in a couple other places, but each of those deserve individual review.
This change is inspired by D137530, but is not directly related to it. I vaguely remember we discussed the tradeoffs of using vmv.v.i in another recent review, but couldn't find it.
Differential Revision: https://reviews.llvm.org/D139648
Now with fix to limit added tagged-globals.ll to risc-v platform
--
[RISC-V][HWASAN] Support tagging global variables for RISC-V HWASAN
Reviewed by: luismarques
Differential Revision: https://reviews.llvm.org/D132995
For reductions, we need to put the start value into a source vector. For fractional LMULs, we can perform the operation at the original LMUL. For LMUL > 1, we eventually want to use a scalar insert, but that's outside the scope of this patch.
Differential Revision: https://reviews.llvm.org/D139747
The patch also added function expandVPBITREVERSE to expand ISD::VP_BITREVERSE nodes.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D139697
We can consolidate code and clarify edge case behavior at the same time.
There are two functional differences here.
First, I remove the ResVT handling, and always use the reduction element type. This appears to be dead code. There's no test coverage, and this code doesn't need to account for scalar type legalization anyways.
Second, if the VL happens to be known non-zero, we can avoid passing through start. This is mostly needed to allow reuse of the existing code; I don't consider it interesting as an optimization on it's own.
Differential Revision: https://reviews.llvm.org/D139733
There's several patches in flght which change this code, better to only have one copy.
The VP case is left seperate for the moment as the result value type differs.
I've enabled Zfhmin on 2 basic tests to show this isn't
completely broken.
Reviewed By: monkchiang
Differential Revision: https://reviews.llvm.org/D139562
This reverts commit 7883e5b061bdbbe8bee5f479ebe911db5045b7e9.
The original commit was reverted that it didn't update test files after D136263
landed. The recommit fixed those.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D139509
The Zfhmin subset only has FLH, FSH, FMV.X.H, FMV.H.X, FCVT.S.H, and FCVT.H.S.
If the D extension is present, the FCVT.D.H and FCVT.H.D instructions are also included.
Since most instructions are not included for Zfhmin, so most operations are promoted.
The patch primarily about making f16 a legal type.
RISC-V ISA info:
https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D139391
The patch made VectorLegalizer expand ISD::VP_FSHL and ISD::VP_FSHR to
achieve the codegen.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D138379
This patch implements shouldFoldSelectWithIdentityConstant for RISCV. It would try to generate vmerge after the binary instruction and let them folded to maksed instruction later.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D131551
