This is the DAG equivalent of D51433.
If we know we're not using all vector lanes, use that knowledge to potentially simplify a vselect condition.
The reduction/horizontal tests show that we are eliminating AVX1 operations on the upper half of 256-bit
vectors because we don't need those anyway.
I'm not sure what the pr34592 test is showing. That's run with -O0; is SimplifyDemandedVectorElts supposed
to be running there?
Differential Revision: https://reviews.llvm.org/D51696
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@341762 91177308-0d34-0410-b5e6-96231b3b80d8
This reduces most of the sdiv stages (the MULHS, shifts etc.) to just zero/identity values and use the numerator scale factor to multiply by +1/-1.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@340260 91177308-0d34-0410-b5e6-96231b3b80d8
This patch refactors the existing TargetLowering::BuildSDIV base implementation to support non-uniform constant vector denominators.
This is the last patch necessary to close PR36545
Differential Revision: https://reviews.llvm.org/D50765
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@339908 91177308-0d34-0410-b5e6-96231b3b80d8
Pull out magic factor calculators into a helper function, use 0/+1/-1 multiplication factor to (optionally) add/sub the numerator.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@339898 91177308-0d34-0410-b5e6-96231b3b80d8
Pull out some types to match layout in TargetLowering::BuildUDIV. Early step towards adding non-uniform vector support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@339763 91177308-0d34-0410-b5e6-96231b3b80d8
We were checking for all bits being Known by checking Known.Zero|Known.One, but if all the bits are known then the value should be a Constant and we can just check for that instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@339509 91177308-0d34-0410-b5e6-96231b3b80d8
Provide a pass-through of the numerator for divide by one cases - this is the same approach we take in DAGCombiner::visitSDIVLike.
I investigated whether we could achieve this by magic MULHU/SRL values but nothing appeared to work as we don't have a way for MULHU(x,c) -> x
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@339254 91177308-0d34-0410-b5e6-96231b3b80d8
As requested in D50392, this is a minor refactor to BuildExactSDIV to stop taking the uniform constant APInt divisor and instead extract it locally.
I also cleanup the operands and valuetypes to better match BuildUDiv (and BuildSDIV in the near future).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@339246 91177308-0d34-0410-b5e6-96231b3b80d8
This patch refactors the existing TargetLowering::BuildUDIV base implementation to support non-uniform constant vector denominators.
It also includes a fold for MULHU by pow2 constants to SRL which can now more readily occur from BuildUDIV.
Differential Revision: https://reviews.llvm.org/D49248
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@339121 91177308-0d34-0410-b5e6-96231b3b80d8
Add a parameter for testing specifically for
sNaNs - at least one instruction pattern on AMDGPU
needs to check specifically for this.
Also handle more cases, and add a target hook
for custom nodes, similar to the hooks for known
bits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338910 91177308-0d34-0410-b5e6-96231b3b80d8
First step towards a BuildSDIV equivalent to D49248 for non-uniform vector support - this just pushes the splat detection down into TargetLowering::BuildSDIV where its still used.
Differential Revision: https://reviews.llvm.org/D50185
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338838 91177308-0d34-0410-b5e6-96231b3b80d8
The vector contains the SDNodes that these functions create. The number of nodes is always a small number so we should use SmallVector to avoid a heap allocation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338329 91177308-0d34-0410-b5e6-96231b3b80d8
This removes the need for an assert to ensure the pointer isn't null.
Years ago we had ifs the checked the pointer was non-null before very access to the vector. These checks were removed and replaced with a single assert. But a reference seems more suitable here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338205 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
A follow-up for D49266 / rL337166.
At least one of these cases is more canonical,
so we really do have to handle it.
https://godbolt.org/g/pkzP3Xhttps://rise4fun.com/Alive/pQyhZZ
We won't get to these cases with I1 being -1,
as that will be constant-folded to true or false.
I'm also not sure we actually hit the 'ule' case,
but i think the worst think that could happen is that being dead code.
Reviewers: spatel, craig.topper, RKSimon, javed.absar, efriedma
Reviewed By: spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D49497
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338044 91177308-0d34-0410-b5e6-96231b3b80d8
scalarizeVectorLoad creates MERGE_VALUES nodes which are immediately
decomposed in expandLoad. Elide the node in these cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337708 91177308-0d34-0410-b5e6-96231b3b80d8
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46290
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@331272 91177308-0d34-0410-b5e6-96231b3b80d8
If we get into the right hand side of the OR, we know that isOpaque is true since the left hand size is just a check that it's false.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327179 91177308-0d34-0410-b5e6-96231b3b80d8
We were checking the condition code a second time when we were already in a block with this same condition code check.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327069 91177308-0d34-0410-b5e6-96231b3b80d8
This supports things like
(setcc ugt X, 0) -> (setcc ne X, 0)
I've restricted to only make changes to vectors before legalize ops because I doubt all targets have accurate condition code legality information for vectors given how little we did before.
Differential Revision: https://reviews.llvm.org/D42948
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326495 91177308-0d34-0410-b5e6-96231b3b80d8
isCondCodeLegal internally checked Legal or Custom which is misleading. Though no targets set any cond code action to Custom today.
So I've renamed isCondCodeLegal to isCondCodeLegalOrCustom and added a real isCondCodeLegal that only checks Legal.
I've changed legalization code to use isCondCodeLegalOrCustom and left things reachable via DAG combine as isCondCodeLegal. I've also changed some places that called getCondCodeAction and compared to Legal to just use isCondCodeLegal.
I'm looking at trying to keep SETCC all the way to isel for the AVX512 integer comparisons and I suspect I'll need to make some condition codes Custom to stop DAG combine from changing things post LegalizeOps. Prior to this only Expand stopped DAG combine, but that causes LegalizeOps to try to swap operands or invert rather than calling our Custom handler.
Differential Revision: https://reviews.llvm.org/D43607
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325829 91177308-0d34-0410-b5e6-96231b3b80d8
This is split off from D42948 and includes just the cases that constant fold to true or false. It also includes some refactoring to keep predicate checks together.
This supports things like
(setcc uge X, 0) -> true
Differential Revision: https://reviews.llvm.org/D43489
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325627 91177308-0d34-0410-b5e6-96231b3b80d8
DAGCombiner and SimplifySetCC both use getPointerTy for shift amounts pre-legalization. DAGCombiner uses a single helper function to hide this. SimplifySetCC does it in multiple places.
This patch adds a defaulted parameter to getShiftAmountTy that can make it return getPointerTy for scalar types. Use this parameter to simplify the SimplifySetCC and DAGCombiner.
Additionally, there were two places in SimplifySetCC that were creating shifts using the target's preferred shift amount pre-legalization. If the target uses a narrow type and the type is illegal, this can cause SimplfiySetCC to create a shift with an amount that can't represent all possible shift values for the type. To fix this we should use pointer type there too.
Alternatively we could make getScalarShiftAmountTy for each target return a safe value for large types as proposed in D43445. And maybe we should still do that, but fixing the SimplifySetCC code keeps other targets from tripping over this in the future.
Fixes PR36250.
Differential Revision: https://reviews.llvm.org/D43449
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325602 91177308-0d34-0410-b5e6-96231b3b80d8
Based off the DemandedElts mask the and UNDEF elements returned from the SimplifyDemandedVectorElts calls to the shuffle operands, we can attempt to simplify the shuffle mask.
I had to be very conservative here as accepting post-legalized shuffle masks could cause problems for targets that legalize UNDEF mask elements back to inrange values (PowerPC), similarly combining to identity shuffle masks could cause too much UNDEF information to disappear for later combines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325354 91177308-0d34-0410-b5e6-96231b3b80d8
This just adds a basic pass through - we can add constant selection mask handling in a future patch to fully match InstCombine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325338 91177308-0d34-0410-b5e6-96231b3b80d8
This is mainly a move of simplifyShuffleOperands from DAGCombiner::visitVECTOR_SHUFFLE to create a more general purpose TargetLowering::SimplifyDemandedVectorElts implementation.
Further features can be moved/added in future patches.
Differential Revision: https://reviews.llvm.org/D42896
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325232 91177308-0d34-0410-b5e6-96231b3b80d8