| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
test cases.
llvm-svn: 209877
|
| |
|
|
|
|
|
|
|
|
| |
Vectorizer.
This patch adds support to vectorize intrinsics such as powi, cttz and ctlz in Vectorizer. These intrinsics are different from other
intrinsics as second argument to these function must be same in order to vectorize them and it should be represented as a scalar.
Review: http://reviews.llvm.org/D3851#inline-32769 and http://reviews.llvm.org/D3937#inline-32857
llvm-svn: 209873
|
| |
|
|
|
|
|
| |
I'm using this pretty frequently in a patch I'm working on and it seems
generally useful.
llvm-svn: 209872
|
| |
|
|
| |
llvm-svn: 209871
|
| |
|
|
|
|
| |
that a pointer argument may be passed through a callsite to the return, and that we may need to analyze it. Fixes a bug reported on llvm-dev: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073098.html
llvm-svn: 209870
|
| |
|
|
|
|
| |
We should only run this if X86 is in the targets.
llvm-svn: 209866
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The corresponding CFE patch replaces these intrinsics with vector initializers
in avxintrin.h. This patch removes the LLVM intrinsics from the backend.
We now stop lowering at X86ISD::VBROADCAST custom node rather than lowering
that further to the intrinsics.
The patch only changes VBROADCASTS* and leaves VBROADCAST[FI]128 to continue
to use intrinsics. As explained in the CFE patch, the reason is that we
currently don't generate as good code for them without the intrinsics.
CodeGen/X86/avx-vbroadcast.ll already provides coverage for this change. It
checks that for a series of insertelements we generate the appropriate
vbroadcast instruction.
Also verified that there was no assembly change in the test-suite before and
after this patch.
llvm-svn: 209864
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
They are replaced with the same IR that is generated for the
vector-initializers in avxintrin.h.
The test verifies that we get back the original instruction. I haven't seen
this approach to be used in other auto-upgrade tests (i.e. llc + FileCheck)
but I think it's the most direct way to test this case. I believe this should
work because llc upgrades calls during parsing. (Other tests mostly check
that assembling and disassembling yields the upgraded IR.)
llvm-svn: 209863
|
| |
|
|
|
|
|
|
|
| |
original fix would actually trigger the *exact* same crasher as the
original bug for a different reason. Awesomesauce.
Working on test cases now, but wanted to get bots healthier.
llvm-svn: 209860
|
| |
|
|
|
|
|
|
|
|
| |
across PHI nodes. The code was computing the Idxs from the 'GEP'
variable's indices when what it wanted was Op1's indices. This caused an
ASan heap-overflow for me that pin pointed the issue when Op1 had more
indices than GEP did. =] I'll let Louis add a specific test case for
this if he wants.
llvm-svn: 209857
|
| |
|
|
| |
llvm-svn: 209855
|
| |
|
|
|
|
|
|
|
|
|
| |
The loop vectorizer instantiates be-taken-count + 1 as the loop iteration count.
If this expression overflows the generated code was invalid.
In case of overflow the code now jumps to the scalar loop.
Fixes PR17288.
llvm-svn: 209854
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These tests ensure that a change I will propose in clang works as
expected.
Summary:
Added tests for the generation of blend+immediate instructions from a
shufflevector.
These tests were proposed along with a patch that was dropped. I'm
committing the tests anyway to protect against possible regressions in
codegen.
Reviewers: nadav, bkramer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D3600
llvm-svn: 209853
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently LLVM will generally merge GEPs. This allows backends to use more
complex addressing modes. In some cases this is not happening because there
is PHI inbetween the two GEPs:
GEP1--\
|-->PHI1-->GEP3
GEP2--/
This patch checks to see if GEP1 and GEP2 are similiar enough that they can be
cloned (GEP12) in GEP3's BB, allowing GEP->GEP merging (GEP123):
GEP1--\ --\ --\
|-->PHI1-->GEP3 ==> |-->PHI2->GEP12->GEP3 == > |-->PHI2->GEP123
GEP2--/ --/ --/
This also breaks certain use chains that are preventing GEP->GEP merges that the
the existing instcombine would merge otherwise.
Tests included.
llvm-svn: 209843
|
| |
|
|
| |
llvm-svn: 209840
|
| |
|
|
|
|
|
|
| |
without this case we would end on an infinite recursion: the remainder is zero,
so Numerator - Remainder is equal to Numerator and so we would recursively ask
for the division of Numerator by Denominator.
llvm-svn: 209838
|
| |
|
|
|
|
|
|
| |
when ScalarEvolution::getElementSize returns nullptr it is safe to early return
in ScalarEvolution::findArrayDimensions such that we avoid later problems when
we try to divide the terms by ElementSize.
llvm-svn: 209837
|
| |
|
|
| |
llvm-svn: 209834
|
| |
|
|
|
|
|
|
|
| |
This makes it slightly harder to misuse Twines. It is still possible to
refer to destroyed temporaries with the regular constructors, though.
Patch by Marco Alesiani!
llvm-svn: 209832
|
| |
|
|
|
|
|
| |
never used again and updating the abstract variable for each inlined
instance of it was questionable in the first place.
llvm-svn: 209829
|
| |
|
|
| |
llvm-svn: 209822
|
| |
|
|
|
|
|
|
|
|
|
| |
This seems to match what gcc does for ppc and what every other llvm
backend does.
This is a fixed version of r209638. The difference is to avoid any change
in behavior for functions. The logic for using constant pools for function
addresseses is spread over a few places and we have to keep them in sync.
llvm-svn: 209821
|
| |
|
|
|
|
| |
This would have found the miscompile in r209638.
llvm-svn: 209820
|
| |
|
|
|
|
|
|
|
|
| |
overflows."""
This reverts commit r209776.
It was miscompiling llvm::SelectionDAGISel::MorphNode.
llvm-svn: 209817
|
| |
|
|
|
|
| |
disassembly for NV
llvm-svn: 209803
|
| |
|
|
| |
llvm-svn: 209802
|
| |
|
|
|
|
|
| |
field represents ELF section header sh_info field and does not have any
sense for regular sections. Its interpretation depends on section type.
llvm-svn: 209801
|
| |
|
|
| |
llvm-svn: 209799
|
| |
|
|
| |
llvm-svn: 209798
|
| |
|
|
|
|
|
|
|
|
| |
During loop-unroll, loop exits from the current loop may end up in in different
outer loop. This requires to re-form LCSSA recursively for one level down from
the outer most loop where loop exits are landed during unroll. This fixes PR18861.
Differential Revision: http://reviews.llvm.org/D2976
llvm-svn: 209796
|
| |
|
|
| |
llvm-svn: 209792
|
| |
|
|
|
|
|
|
| |
This pass is disabled by default. Use -combine-loads to enable in -O[1-3]
Differential revision: http://reviews.llvm.org/D3580
llvm-svn: 209791
|
| |
|
|
|
|
|
|
|
| |
Clang knows about the sanitizer blacklist and it makes no sense to
add global to the list of llvm.asan.dynamically_initialized_globals if it
will be blacklisted in the instrumentation pass anyway. Instead, we should
do as much blacklisting as possible (if not all) in the frontend.
llvm-svn: 209790
|
| |
|
|
|
|
|
|
| |
An address only use of an extract element of a load can be simplified to a
load. Without this the result of the extract element is spilled to the
stack so that an address is available.
llvm-svn: 209788
|
| |
|
|
|
|
|
| |
These are confusing enough since the order swaps,
so give them more useful names.
llvm-svn: 209787
|
| |
|
|
| |
llvm-svn: 209784
|
| |
|
|
|
|
|
|
|
|
|
|
| |
runtime.
Don't assume that dynamically initialized globals are all initialized from
_GLOBAL__<module_name>I_ function. Instead, scan the llvm.global_ctors and
insert poison/unpoison calls to each function there.
Patch by Nico Weber!
llvm-svn: 209780
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add a function to combine two 32-bit integers into a 64-bit integer.
There are no calls to this function yet, although a subsequent change
will add some in LLDB.
Reviewers: rnk
Differential Revision: http://reviews.llvm.org/D3941
llvm-svn: 209777
|
| |
|
|
|
|
|
|
| |
overflows.""
This reverts commit r209762, bringing back r209746. It was not responsible for the libc++ build failure
llvm-svn: 209776
|
| |
|
|
|
|
|
|
| |
This reverts commit r209755.
it was the real cause of the libc++ build failure.
llvm-svn: 209775
|
| |
|
|
|
|
|
|
|
| |
No test because no in-tree targets change the bitwidth of the
setcc type depending on the bitwidth of the compared type.
Patch by Ke Bai
llvm-svn: 209771
|
| |
|
|
| |
llvm-svn: 209770
|
| |
|
|
| |
llvm-svn: 209768
|
| |
|
|
| |
llvm-svn: 209763
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r209746.
It looks it is causing a crash while building libcxx. I am trying to get a
reduced testcase.
llvm-svn: 209762
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, DataTypes.h would #define a variety of symbols any time
they weren't already defined. However, some versions of Visual
Studio do provide the appropriate headers, so if those headers are
included after DataTypes.h, it can lead to macro redefinition
warnings.
The fix is to include the appropriate headers if they exist, and
only #define the symbols if the required header does not exist.
Patch by Zachary Turner!
---
The big change here is that we no longer have our own stdint.h
typedefs because now all supported toolchains have stdint.h.
Hooray!
llvm-svn: 209760
|
| |
|
|
|
|
|
|
|
|
| |
This matches gcc's behavior. It also seems natural given that aliases
contain other properties that govern how it is accessed (linkage,
visibility, dll storage).
Clang still has to be updated to expose this feature to C.
llvm-svn: 209759
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently LLVM will generally merge GEPs. This allows backends to use more
complex addressing modes. In some cases this is not happening because there
is PHI inbetween the two GEPs:
GEP1--\
|-->PHI1-->GEP3
GEP2--/
This patch checks to see if GEP1 and GEP2 are similiar enough that they can be
cloned (GEP12) in GEP3's BB, allowing GEP->GEP merging (GEP123):
GEP1--\ --\ --\
|-->PHI1-->GEP3 ==> |-->PHI2->GEP12->GEP3 == > |-->PHI2->GEP123
GEP2--/ --/ --/
This also breaks certain use chains that are preventing GEP->GEP merges that the
the existing instcombine would merge otherwise.
Tests included.
llvm-svn: 209755
|
| |
|
|
|
|
|
|
|
|
| |
value is live"
This reverts r208640 (I've just XFAILed the test) because it broke ppc64/Linux
self-hosting. Because nearly every regression test triggers a segfault, I hope
this will be easy to fix.
llvm-svn: 209747
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements two things:
1. If we know one number is positive and another is negative, we return true as
signed addition of two opposite signed numbers will never overflow.
2. Implemented TODO : If one of the operands only has one non-zero bit, and if
the other operand has a known-zero bit in a more significant place than it
(not including the sign bit) the ripple may go up to and fill the zero, but
won't change the sign. e.x - (x & ~4) + 1
We make sure that we are ignoring 0 at MSB.
Patch by Suyog Sarda.
llvm-svn: 209746
|