When considering merging stores values are the results of loads only
consider stores whose values come from loads from the same base.
This fixes much of the longer compile times in PR33330.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304934 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Check that the first access before one being tested is valid.
Before this patch, if there was no definition prior to the Use being tested,
the first time Iter was deferenced, it hit the sentinel.
Reviewers: dberlin, gbiv
Subscribers: sanjoy, Prazek, llvm-commits
Differential Revision: https://reviews.llvm.org/D33950
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304926 91177308-0d34-0410-b5e6-96231b3b80d8
This could be viewed as another shortcoming of the DAGCombiner:
when both operands of a compare are zexted from the same source
type, we should be able to compare the original types.
The effect on PowerPC perf is likely unnoticeable, but there's a
visible regression for x86 if we feed the suboptimal IR for memcmp
expansion to the DAG:
_cmp_eq4_zexted_to_i64:
movl (%rdi), %ecx
movl (%rsi), %edx
xorl %eax, %eax
cmpq %rdx, %rcx
sete %al
_cmp_eq4_better:
movl (%rdi), %ecx
xorl %eax, %eax
cmpl (%rsi), %ecx
sete %al
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304923 91177308-0d34-0410-b5e6-96231b3b80d8
This makes it so that the code quality for CFI checks when compiling
with -O2 and linking with --lto-O0 is similar to that of the rest of
the code.
Reduces the size of a chrome binary built with -O2/--lto-O0 by
about 750KB.
Differential Revision: https://reviews.llvm.org/D33925
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304921 91177308-0d34-0410-b5e6-96231b3b80d8
Changed immediate type for repl.ph from uimm10 to simm10 as per the specs.
Repl.qb still accepts uimm8. Both instructions now mimic the behaviour of
GNU as.
Patch by Stefan Maksimovic.
Differential Revision: https://reviews.llvm.org/D33594
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304918 91177308-0d34-0410-b5e6-96231b3b80d8
If we know that both operands of an unsigned integer vector comparison are non-negative,
then it's safe to directly use a signed-compare-greater-than instruction (the only non-equality
integer vector compare predicate provided by SSE/AVX).
We're intentionally not changing the condition code to signed in order to preserve the
existing transforms that use min/max/psubus below here.
This should solve PR33276:
https://bugs.llvm.org/show_bug.cgi?id=33276
Differential Revision: https://reviews.llvm.org/D33862
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304909 91177308-0d34-0410-b5e6-96231b3b80d8
In the special (but also the likely common) case, we can avoid
the multi-block complexity of the general algorithm, so moving
this part off on its own will make it re-usable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304908 91177308-0d34-0410-b5e6-96231b3b80d8
The clang compiler by default uses FastISel when invoked with -O0, which
is also the default. In that case, passing of -mxgot does not get honored,
i.e. the code path that is to deal with large got is not taken.
Clang produces same output regardless of -mxgot being present or not.
This change checks whether -mxgot is passed as an option, and turns off
FastISel if it is.
Patch by Stefan Maksimovic.
Differential Revision: https://reviews.llvm.org/D33593
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304906 91177308-0d34-0410-b5e6-96231b3b80d8
According to the commit message from r296921, G_MERGE_VALUES and
G_INSERT are to be preferred over G_SEQUENCE. Therefore, stop generating
G_SEQUENCE in the ARM backend and remove the code dealing with it.
This boils down to the code breaking up double values for the soft float
calling convention. Use G_MERGE_VALUES + G_UNMERGE_VALUES instead of
G_SEQUENCE + G_EXTRACT for it. This maps very nicely to VMOVDRR +
VMOVRRD and simplifies the code in the instruction selector.
There's one occurence of G_SEQUENCE left in arm-irtranslator.ll, but
that is part of the target-independent code for translating constant
structs. Therefore, it is beyond the scope of this commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304902 91177308-0d34-0410-b5e6-96231b3b80d8
If there's enough data in fron of it the skipped region would just
become arbitrarily large, and we scan for the CHECK-NOT everywhere.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304900 91177308-0d34-0410-b5e6-96231b3b80d8
Same as the other binary operators:
- legalize to 32 bits
- map to GPRs
- select to EORrr via TableGen'erated code
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304898 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r301394. It broke some internal buildbots, reverting
while the issue is being investigated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304896 91177308-0d34-0410-b5e6-96231b3b80d8
We were checking that the index was in range of the destination vector type, not the (larger) source vector type
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304894 91177308-0d34-0410-b5e6-96231b3b80d8
Same as the other binary operators:
- legalize to 32 bits
- map to GPRs
- select ORRrr thanks to TableGen'erated code
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304890 91177308-0d34-0410-b5e6-96231b3b80d8
This is identical to the support for the other binary operators:
- widen to s32
- map into GPR
- select ANDrr (via TableGen'erated code)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304885 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch updates Triple::isCompatibleWith to make armxx and thumbxx
triples compatible, as long as the subarch, vendor, os, envorionment and
object format match. Thumb/ARM code generation should be controlled
using the thumb-mode per-function target feature rather than by the
triple to allow mixing Thumb and ARM functions.
D33448 updates Clang's codegen to add thumb-mode for all functions with
armxx or thumbxx triples.
Reviewers: echristo, t.p.northover, rafael, kristof.beyls, rengolin, tejohnson
Reviewed By: tejohnson
Subscribers: rinon, eugenis, pcc, srhines, aemerson, mehdi_amini, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D33287
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304884 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Relocations are required for unconditional branches to function symbols with
different execution mode. Without this patch, incorrect branches are
generated for tail calls between functions with different execution
mode.
Reviewers: peter.smith, rafael, echristo, kristof.beyls
Reviewed By: peter.smith
Subscribers: aemerson, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D33898
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304882 91177308-0d34-0410-b5e6-96231b3b80d8
These methods are specifically optimized to only counting leading zeros without an additional uint64_t compare.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304876 91177308-0d34-0410-b5e6-96231b3b80d8
I believe this code used to use APInt references which would have worked. But then they were changed to pointers to allow m_APInt to be used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304875 91177308-0d34-0410-b5e6-96231b3b80d8
This creates a new library called BinaryFormat that has all of
the headers from llvm/Support containing structure and layout
definitions for various types of binary formats like dwarf, coff,
elf, etc as well as the code for identifying a file from its
magic.
Differential Revision: https://reviews.llvm.org/D33843
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304864 91177308-0d34-0410-b5e6-96231b3b80d8
Previously you would have to use operator==(uint64_t) which does the getActiveBits call and a uint64_t comparison. But we can get all we need to know from the getActiveBits call.
This method will be used in another commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304854 91177308-0d34-0410-b5e6-96231b3b80d8
A few tests in llvm/test/Transforms/Util/PredicateInfo/ are using -reverse-iterate.
The option -reverse-iterate is enabled with +Asserts in usual cases, but it can be turned on/off regardless of LLVM_ENABLE_ASSERTIONS.
I wonder if this were incompatible to https://reviews.llvm.org/D33908 (r304757).
Differential Revision: https://reviews.llvm.org/D33854
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304851 91177308-0d34-0410-b5e6-96231b3b80d8
