By using a union for Constant* and ConstantRange we can shave off ptr
size bytes off lattice elements. On 64 bit systems, it brings down the
size to 40 bytes from 48 bytes.
Initialization of Range happens on-demand using placement new, if the
state changes to constantrange from non-constantrange. Similarly, the
Range object is destroyed if the state changes from constantrange to
non-constantrange.
Reviewers: reames, anna, davide
Reviewed By: reames, davide
Differential Revision: https://reviews.llvm.org/D41903
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@323049 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch adds an implementation of targetShrinkDemandedConstant that tries to keep shrinkdemandedbits from removing bits that would otherwise have been recognized as a movzx.
We still need a follow patch to stop moving ands across srl if the and could be represented as a movzx before the shift but not after. I think this should help with some of the cases that D42088 ended up removing during isel.
Reviewers: spatel, RKSimon
Reviewed By: spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42265
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@323048 91177308-0d34-0410-b5e6-96231b3b80d8
The existing tests just tested shuffles of v32i1 inputs, but arguments are promoted to v32i8. So it wasn't a good demonstration of v32i1 shuffle handling.
The new test cases use compares and selects to get k-register operations around the shuffle.
This is prep work for demonstrating changes from D42031.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@323031 91177308-0d34-0410-b5e6-96231b3b80d8
`llvm.used` contains a list of pointers to named values which the
compiler, assembler, and linker are required to treat as if there is a
reference that they cannot see. Ensure that the symbols are preserved
by adding an explicit `-include` reference to the linker command.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@323017 91177308-0d34-0410-b5e6-96231b3b80d8
This change applies to places where we would turn 128/256-bit code into 512-bit in order to get a wider element type through sext/zext. Any 512-bit types that already existed in the IR/DAG will be left that way.
The width preference has no effect on codegen behavior when the target does not have AVX512 enabled. So AVX/AVX2 codegen cannot be limited via this mechanism yet.
If the preference is lower than 256 we may still use a 256 bit type to do the operation. Constraining to 128 bits makes it much more difficult to support some operations. For many of these cases we need to change element width while keeping element count constant which is easiest done by switching between 256 and 128 bit.
The preference is only obeyed when AVX512 and VLX are available. This means the preference is not obeyed for KNL, but is obeyed for SKX, Cannonlake, and Icelake. For KNL, the only way to do masked operation is on 512-bit registers so we would have to completely disable masking to obey the preference. We would also lose support for gather, scatter, ctlz, vXi64 multiplies, etc. This may change in the future, but this simplifies the initial implementation.
Differential Revision: https://reviews.llvm.org/D41895
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@323016 91177308-0d34-0410-b5e6-96231b3b80d8
This will cause the vectorizers to do some limiting of the vector widths they create. This is not a strict limit. There are reasons I know of that the loop vectorizer will generate larger vectors for.
I've written this in such a way that the interface will only return a properly supported width(0/128/256/512) even if the attribute says something funny like 384 or 10.
This has been split from D41895 with the remainder in a follow up commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@323015 91177308-0d34-0410-b5e6-96231b3b80d8
to @objc_autorelease if its operand is a PHI and the PHI has an
equivalent value that is used by a return instruction.
For example, ARC optimizer shouldn't replace the call in the following
example, as doing so breaks the AutoreleaseRV/RetainRV optimization:
%v1 = bitcast i32* %v0 to i8*
br label %bb3
bb2:
%v3 = bitcast i32* %v2 to i8*
br label %bb3
bb3:
%p = phi i8* [ %v1, %bb1 ], [ %v3, %bb2 ]
%retval = phi i32* [ %v0, %bb1 ], [ %v2, %bb2 ] ; equivalent to %p
%v4 = tail call i8* @objc_autoreleaseReturnValue(i8* %p)
ret i32* %retval
Also, make sure ObjCARCContract replaces @objc_autoreleaseReturnValue's
operand uses with its value so that the call gets tail-called.
rdar://problem/15894705
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@323009 91177308-0d34-0410-b5e6-96231b3b80d8
ExternalSymbolMap now stores the string key (rather than using a StringRef),
as the object file backing the key may be removed at any time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@323001 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch attempts to fix the DomTree incremental insertion bug found here [[ https://bugs.llvm.org/show_bug.cgi?id=35969 | PR35969 ]] .
When performing an insertion into a piece of unreachable CFG, we may find the same not at different levels. When this happens, the node can turn out to be affected when we find it starting from a node with a lower level in the tree. The level at which we start visitation affects if we consider a node affected or not.
This patch tracks the lowest level at which each node was visited during insertion and allows it to be visited multiple times, if it can cause it to be considered affected.
Reviewers: brzycki, davide, dberlin, grosser
Reviewed By: brzycki
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42231
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322993 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, the DIBuilder didn't expose functionality to set its compile unit
in any other way than calling createCompileUnit. This meant that the outliner,
which creates new functions, had to create a new compile unit for its debug
info.
This commit adds an optional parameter in the DIBuilder's constructor which
lets you set its CU at construction.
It also changes the MachineOutliner so that it keeps track of the DISubprograms
for each outlined sequence. If debugging information is requested, then it
uses one of the outlined sequence's DISubprograms to grab a CU. It then uses
that CU to construct the DISubprogram for the new outlined function.
The test has also been updated to reflect this change.
See https://reviews.llvm.org/D42254 for more information. Also see the e-mail
discussion on D42254 in llvm-commits for more context.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322992 91177308-0d34-0410-b5e6-96231b3b80d8
On current machines we have load-on-condition instructions that can be
used to directly implement the SETCC semantics. If we have those, it is
always preferable to use them instead of generating the IPM sequence.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322989 91177308-0d34-0410-b5e6-96231b3b80d8
In order to implement a test whether a compare-and-swap succeeded, the
SystemZ back-end currently emits a rather inefficient sequence of first
converting the CC result into an integer, and then testing that integer
against zero. This commit changes the back-end to simply directly test
the CC value set by the compare-and-swap instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322988 91177308-0d34-0410-b5e6-96231b3b80d8
The SystemZ back-end uses a sequence of IPM followed by arithmetic
operations to implement the SETCC primitive. This is currently done
early during SelectionDAG. This patch moves generating those sequences
to much later in SelectionDAG (during PreprocessISelDAG).
This doesn't change much in generated code by itself, but it allows
further enhancements that will be checked-in as follow-on commits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322987 91177308-0d34-0410-b5e6-96231b3b80d8
This provides a computeKnownBits implementation for SystemZ target
nodes. Currently only SystemZISD::SELECT_CCMASK is supported.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322986 91177308-0d34-0410-b5e6-96231b3b80d8
The second return value of ATOMIC_CMP_SWAP_WITH_SUCCESS is known to be a
boolean, and should therefore be treated by computeKnownBits just like
the second return values of SMULO / UMULO.
Differential Revision: https://reviews.llvm.org/D42067
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322985 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
For consistency with the output of lld.
This is useful in runnable binaries as can them be sure the
null function pointer will never be a valid argument
call_indirect.
Subscribers: jfb, dschuff, jgravelle-google, aheejin, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D42284
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322978 91177308-0d34-0410-b5e6-96231b3b80d8
Include the LLVM_LIBXML2_ENABLED cache variable in LLVMConfig.cmake
in order to make it available for other LLVM packages to query. This
is necessary to fix stand-alone testing of LLD.
Differential Revision: https://reviews.llvm.org/D42252
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322973 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a performance regression caused by r322737.
While trying to make it easier to replace compares with existing adds and
subtracts, I accidentally stopped it from doing so in some cases. This should
fix that. I'm also fixing another potential bug in that commit.
Differential Revision: https://reviews.llvm.org/D42263
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322972 91177308-0d34-0410-b5e6-96231b3b80d8
RuntimeLibcallSignatures previously manually initialized all the libcall
names into an array and searched it linearly for the first match to lookup
the corresponding index.
r322802 switched that to initializing a map keyed by the libcall name.
Neither of these approaches works correctly because some libcall numbers use
the same name on different platforms (e.g. the "l" suffixed functions
use f80 or f128 or ppcf128).
This change fixes that by ensuring that each name only goes into the map
once. It also adds tests.
Differential Revision: https://reviews.llvm.org/D42271
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322971 91177308-0d34-0410-b5e6-96231b3b80d8
Try to detect the terminal color support by checking the value of the
TERM environment variable. This is not great, but it's better than
nothing when terminfo library isn't available, which may still be the
case on some Linux distributions.
Differential Revision: https://reviews.llvm.org/D42055
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322962 91177308-0d34-0410-b5e6-96231b3b80d8
There were checks for a 32-bit target here, but no RUN line
corresponding to that prefix. I don't know what the intent
of these tests is, but at least now we can see what happens
for both targets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322961 91177308-0d34-0410-b5e6-96231b3b80d8
Try to reverse the constant-shrinking that happens in SimplifyDemandedBits()
for 'and' masks when it results in a smaller sign-extended immediate.
We are also able to detect dead 'and' ops here (the mask is all ones). In
that case, we replace and return without selecting the 'and'.
Other targets might want to share some of this logic by enabling this under a
target hook, but I didn't see diffs for simple cases with PowerPC or AArch64,
so they may already have some specialized logic for this kind of thing or have
different needs.
This should solve PR35907:
https://bugs.llvm.org/show_bug.cgi?id=35907
Differential Revision: https://reviews.llvm.org/D42088
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322957 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
If the vectorized tree has truncate to minimum required bit width and
the vector type of the cast operation after the truncation is the same
as the vector type of the cast operands, count cost of the vector cast
operation as 0, because this cast will be later removed.
Also, if the vectorization tree root operations are integer cast operations, do not consider them as candidates for truncation. It will just create extra number of the same vector/scalar operations, which will be removed by instcombiner.
Reviewers: RKSimon, spatel, mkuper, hfinkel, mssimpso
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41948
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322946 91177308-0d34-0410-b5e6-96231b3b80d8
