promoting a store in a loop.  This was noticed when working on PR14753,
but isn't directly related.

llvm-svn: 171281

PR14753

llvm-svn: 171279

if C1 and C2 differ only with one bit.
Fixes PR14708.

llvm-svn: 171270

Fixes pr14751.

Patch by Kai; Thanks!

llvm-svn: 171261

LCSSA PHIs may have undef values. The vectorizer updates values that are used by outside users such as PHIs.
The bug happened because undefs are not loop values. This patch handles these PHIs.

PR14725

llvm-svn: 171251

This is done to avoid odd test failures, like the one fixed in r171243.

llvm-svn: 171250

This test did not test anything at all (except for opt crashing, but that was
not the reason why it was added).

llvm-svn: 171248

This is done to avoid odd test failures, like the one fixed in r171243.

llvm-svn: 171246

Larry Evans reported it fails if source tree contains "load", like "download".

llvm-svn: 171243

propagating one of the values it simplified to a constant across
a myriad of instructions. Notably, ptrtoint instructions when we had
a constant pointer (say, 0) didn't propagate that, blocking a massive
number of down-stream optimizations.

This was uncovered when investigating why we fail to inline and delete
the boilerplate in:

  void f() {
    std::vector<int> v;
    v.push_back(1);
  }

It turns out most of the efforts I've made thus far to improve the
analysis weren't making it far purely because of this. After this is
fixed, the store-to-load forwarding patch enables LLVM to optimize the
above to an empty function. We still can't nuke a second push_back, but
for different reasons.

There is a very real chance this will cause somewhat noticable changes
in inlining behavior, so please let me know if you see regressions (or
improvements!) because of this patch.

llvm-svn: 171196

how to propagate constants through insert and extract value
instructions.

With the recent improvements to instsimplify, this allows inline cost
analysis to constant fold through intrinsic functions, including notably
the with.overflow intrinsic math routines which often show up inside of
STL abstractions. This is yet another piece in the puzzle of breaking
down the code for:

  void f() {
    std::vector<int> v;
    v.push_back(1);
  }

But it still isn't enough. There are a pile of bugs in inline cost still
blocking this.

llvm-svn: 171195

constant folding calls. Add the initial tests for this which show that
now instsimplify can simplify blindingly obvious code patterns expressed
with both intrinsics and library calls.

llvm-svn: 171194

AVX: Move the ZEXT/ANYEXT DAGCo optimizations to the lowering of these optimizations. The old test cases still cover all of these lowering/optimizations. The single change that we have is that now anyext does not need to zero a register, because it does not use the exact code path as the zero_extend.

llvm-svn: 171178

[ASan] Fix lifetime intrinsics handling. Now for each intrinsic we check if it describes one of 'interesting' allocas. Assume that allocas can go through casts and phi-nodes before apperaring as llvm.lifetime arguments

llvm-svn: 171153

register. In most cases we actually compare or select YMM-sized registers
and mixing the two types creates horrible code. This commit optimizes
some of the transition sequences.

PR14657.

llvm-svn: 171148

per compile unit/skeleton compile unit. Update tests accordingly.

llvm-svn: 171133

llvm-svn: 171132

llvm-svn: 171131

information doesn't return an addend for Rel relocations. Go ahead
and use this information to fix relocation handling inside dwarfdump
for 32-bit ELF REL.

llvm-svn: 171126

If all of the write objects are identified then we can vectorize the loop even if the read objects are unidentified.

PR14719.

llvm-svn: 171124

LoopVectorizer: Optimize the vectorization of consecutive memory access when the iteration step is -1

llvm-svn: 171114

Origin alignment is as high as the alignment of the corresponding application
location, but never less than 4.

llvm-svn: 171110

llvm-svn: 171084

llvm-svn: 171083

For the time being this includes only some dummy test cases. Once the
generic implementation of the intrinsics cost function does something other
than assuming scalarization in all cases, or some target specializes the
interface, some real test cases can be added.

Also, for consistency, I changed the type of IID from unsigned to Intrinsic::ID
in a few other places.

llvm-svn: 171079

llvm-svn: 171076

llvm-svn: 171075

As with the prefetch intrinsic to which it maps, simply have dcbt
marked as reading from and writing to its arguments instead of having
unmodeled side effects. While this might cause unwanted code motion
(because aliasing checks don't really capture cache-line sharing),
it is more important that prefetches in unrolled loops don't block
the scheduler from rearranging the unrolled loop body.

llvm-svn: 171073

Use of store or load with the atomic specifier on 64-bit types would
cause instruction-selection failures. As with the 32-bit case, these
can use the default expansion in terms of cmp-and-swap.

llvm-svn: 171072

VectorType::getInteger() can not be used with them, because pointer size
depends on the target.

llvm-svn: 171070

llvm-svn: 171069

This only failed on hosts that don't have SSE41.

llvm-svn: 171066

llvm-svn: 171064

pcmpeqd, pshufd, pshufd, pand is cheaper than unpack + cmpq, sbbq, cmpq, sbbq + pack.
Small speedup on loop-vectorized viterbi (-march=core2).

llvm-svn: 171063

llvm-svn: 171043

llvm-svn: 171029

Some x86 instructions can load/store one of the operands to memory. On SSE, this memory needs to be aligned.
When these instructions are encoded in VEX (on AVX) there is no such requirement. This changes the folding
tables and removes the alignment restrictions from VEX-encoded instructions.

llvm-svn: 171024

the StoreInst operands.

PR14705.

llvm-svn: 171023

The bug was in the code that detects PHIs in if-then-else block sequence.

PR14701.

llvm-svn: 171008

the cost of arithmetic functions. We now assume that the cost of arithmetic
operations that are marked as Legal or Promote is low, but ops that are
marked as custom are higher.

llvm-svn: 171002