| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
| |
At least the plugin used by the LibreOffice build
(<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly
uses those members (through inline functions in LLVM/Clang include files in turn
using them), but they are not exported by utils/extract_symbols.py on Windows,
and accessing data across DLL/EXE boundaries on Windows is generally
problematic.
Differential Revision: https://reviews.llvm.org/D26671
llvm-svn: 289647
|
|
|
|
|
|
| |
We don't need to extract+test the sign bit of the known ones/zeros, we can use sext which will handle all of this.
llvm-svn: 289534
|
|
|
|
|
|
| |
Pre-commit as discussed on D27657
llvm-svn: 289425
|
|
|
|
|
|
|
|
| |
from 'large element' scalar/vector to 'small element' vector.
Extension to D27129 which already supported bitcasts from 'small element' vector to 'large element' scalar/vector types.
llvm-svn: 289329
|
|
|
|
|
|
| |
Reapplied with fix for PR31323 - X86 SSE2 vXi16 multiplies for illegal types were creating CONCAT_VECTORS nodes with vector inputs that might not total the number of elements in the result type.
llvm-svn: 289232
|
|
|
|
|
|
| |
Makes interception of BUILD_VECTOR creation easier for debugging.
llvm-svn: 289218
|
|
|
|
|
|
| |
Part of the work for PR31323 - add extra asserts checking that the input vectors are of consistent type and result in the correct number of vector elements.
llvm-svn: 289214
|
|
|
|
|
|
|
|
|
|
| |
Adds support for bitcasting a little endian 'small element' vector to 'large element' scalar/vector (e.g. v16i8 to v4i32 or v2i32 to i64), which is required for PR30845. We extract the knownbits for each 'small element' part and concatenate the results together.
We can add support for big endian and 'large element' scalar/vector to 'small element' vector bitcasting once we have test cases for them.
Differential Revision: https://reviews.llvm.org/D27129
llvm-svn: 289200
|
|
|
|
|
|
|
|
| |
This reverts commit r288916 as it is currently causing a crasher in
Halide. Reproducer on llvm.org/PR31323. While it might be that halide is
generating invalid IR, llc shouldn't crash.
llvm-svn: 289194
|
|
|
|
|
|
| |
SMAX/SMIN/UMAX/UMIN opcodes
llvm-svn: 288926
|
|
|
|
| |
llvm-svn: 288916
|
|
|
|
|
|
| |
EXTRACT_VECTOR_ELT does support demanded elts if the element index is known and in range.
llvm-svn: 288913
|
|
|
|
|
|
| |
we don't actually demand that element
llvm-svn: 288839
|
|
|
|
| |
llvm-svn: 288814
|
|
|
|
|
|
|
| |
getNode already prevents formation of out of bounds constant
extract_vector_elts. Do the same for insert_vector_elt.
llvm-svn: 288603
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have the following DAGCombiner transformations:
(mul (shl X, c1), c2) -> (mul X, c2 << c1)
(mul (shl X, C), Y) -> (shl (mul X, Y), C)
(shl (mul x, c1), c2) -> (mul x, c1 << c2)
Usually the constant shift is optimised by SelectionDAG::getNode when it is
constructed, by SelectionDAG::FoldConstantArithmetic, but when we're dealing
with vectors and one of those vector constants contains an undef element
FoldConstantArithmetic does not fold and we enter an infinite loop.
Fix this by making FoldConstantArithmetic use getNode to decide how to fold each
vector element, the same as FoldConstantVectorArithmetic does, and rather than
adding the constant shift to the work list instead only apply the transformation
if it's already been folded into a constant, as if it's not we're going to loop
endlessly. Additionally add missing NoOpaques to one of those transformations,
which I noticed when writing the tests for this.
Differential Revision: https://reviews.llvm.org/D26605
llvm-svn: 287766
|
|
|
|
|
|
|
|
|
|
| |
Add basic ComputeNumSignBits support for TRUNCATE ops for cases where the source's number of sign bits overlaps with the truncated size.
Improves X86 SIGN_EXTEND_IN_REG vector cases which were needlessly sign extending boolean vector results.
Differential Revision: https://reviews.llvm.org/D26851
llvm-svn: 287635
|
|
|
|
| |
llvm-svn: 287541
|
|
|
|
| |
llvm-svn: 287387
|
|
|
|
| |
llvm-svn: 286582
|
|
|
|
| |
llvm-svn: 286578
|
|
|
|
| |
llvm-svn: 286576
|
|
|
|
| |
llvm-svn: 286516
|
|
|
|
| |
llvm-svn: 286509
|
|
|
|
| |
llvm-svn: 286481
|
|
|
|
| |
llvm-svn: 286471
|
|
|
|
| |
llvm-svn: 286461
|
|
|
|
| |
llvm-svn: 286448
|
|
|
|
| |
llvm-svn: 286075
|
|
|
|
| |
llvm-svn: 286071
|
|
|
|
|
|
| |
Avoids APInt construction and slower comparisons.
llvm-svn: 285822
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
computeKnownBits
Currently computeKnownBits returns the common known zero/one bits for all elements of vector data, when we may only be interested in one/some of the elements.
This patch adds a DemandedElts argument that allows us to specify the elements we actually care about. The original computeKnownBits implementation calls with a DemandedElts demanding all elements to match current behaviour. Scalar types set this to 1.
The approach was found to be easier than trying to add a per-element known bits solution, for a similar usefulness given the combines where computeKnownBits is typically used.
I've only added support for a few opcodes so far (the ones that have proven straightforward to test), all others will default to demanding all elements but can be updated in due course.
DemandedElts support could similarly be added to computeKnownBitsForTargetNode in a future commit.
This looked like this had caused compile time regressions on some buildbots (and was reverted in rL285381), but appears to have just been a harmless bystander!
Differential Revision: https://reviews.llvm.org/D25691
llvm-svn: 285494
|
|
|
|
|
|
|
|
| |
no known bits
No need to check the remaining elements - no common known bits are available.
llvm-svn: 285399
|
|
|
|
|
|
| |
No need to clear KnownOne2/KnownZero2 bits as the next call to computeKnownBits will overwrite them anyway
llvm-svn: 285398
|
|
|
|
|
|
| |
SMIN/SMAX/UMIN/UMAX like all other ops
llvm-svn: 285397
|
|
|
|
|
|
|
| |
This seems to have increased LTO compile time bejond 2x of previous builds.
See http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto/10676/
llvm-svn: 285381
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently computeKnownBits returns the common known zero/one bits for all elements of vector data, when we may only be interested in one/some of the elements.
This patch adds a DemandedElts argument that allows us to specify the elements we actually care about. The original computeKnownBits implementation calls with a DemandedElts demanding all elements to match current behaviour. Scalar types set this to 1.
The approach was found to be easier than trying to add a per-element known bits solution, for a similar usefulness given the combines where computeKnownBits is typically used.
I've only added support for a few opcodes so far (the ones that have proven straightforward to test), all others will default to demanding all elements but can be updated in due course.
DemandedElts support could similarly be added to computeKnownBitsForTargetNode in a future commit.
Differential Revision: https://reviews.llvm.org/D25691
llvm-svn: 285296
|
|
|
|
|
|
|
|
|
|
| |
or vector splats
Use isConstOrConstSplat helper.
Also use APInt instead of getZExtValue directly to avoid out of range issues.
llvm-svn: 285033
|
|
|
|
| |
llvm-svn: 285025
|
|
|
|
|
|
|
| |
It is already part of the type (which is part of the global, which is already
being added), so there's no need to do it.
llvm-svn: 285002
|
|
|
|
| |
llvm-svn: 284953
|
|
|
|
|
|
| |
Also, use APInt to avoid crashing on types larger than vNi64.
llvm-svn: 284874
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The scalar version of this pattern was noted in:
https://reviews.llvm.org/D25485
and fixed with:
https://reviews.llvm.org/rL284395
More refactoring of the constant/splat helpers is needed and will happen in follow-up patches.
Differential Revision: https://reviews.llvm.org/D25685
llvm-svn: 284424
|
|
|
|
|
|
|
|
|
|
|
|
| |
As noted in:
https://reviews.llvm.org/D25685
This is the next-to-smallest step needed to enable the ComputeNumSignBits fix in that patch.
In a minor attempt to keep some structure, we're pulling the FP helper over along with its
integer sibling, but clearly we can and should do more refactoring of the similar helper
functions in DAGCombiner and SelectionDAG to simplify and not duplicate functionality.
llvm-svn: 284421
|
|
|
|
|
|
|
|
| |
SelectionDAG::getConstantPool will automatically determine an appropriate alignment if one is not specified. It does this by querying the type's preferred alignment. This can end up creating quite a lot of padding when the preferred alignment for vectors is 128.
In optimize-for-size mode, it makes sense to instead query the ABI type alignment which is often smaller and causes less padding.
llvm-svn: 284381
|
|
|
|
|
|
|
|
| |
SDNode to MachineMemOperand, and remove redundant getAtomic* member functions from SelectionDAG.
Differential Revision: https://reviews.llvm.org/D24577
llvm-svn: 284312
|
|
|
|
|
|
|
|
|
|
| |
Masked-expand-load node represents load operation that loads a variable amount of elements from memory according to amount of "true" bits in the mask and expands the loaded elements according to their position in the mask vector.
Right now, the node is used in intrinsics for VEXPAND* instructions.
The work is done towards implementation of masked.expandload and masked.compressstore intrinsics.
Differential Revision: https://reviews.llvm.org/D25322
llvm-svn: 283694
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D24435
llvm-svn: 283505
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
through EXTRACT_VECTOR_ELT.
Summary: Both computeKnownBits and ComputeNumSignBits can now do a simple
look-through of EXTRACT_VECTOR_ELT. It will compute the result based
on the known bits (or known sign bits) for the vector that the element
is extracted from.
Reviewers: bogner, tstellarAMD, mkuper
Subscribers: wdng, RKSimon, jyknight, llvm-commits, nhaehnle
Differential Revision: https://reviews.llvm.org/D25007
llvm-svn: 283347
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D23984
llvm-svn: 282381
|