It's unnecessary and makes the generated assembly less faithful to the original source.

llvm-svn: 166440

Part of rdar://12470317

llvm-svn: 166436

deterministic, replace it with a DenseMap<std::pair<unsigned, unsigned>,
PHINode*> (we already have a map from BasicBlock to unsigned).

<rdar://problem/12541389>

llvm-svn: 166435

CodeGen in the front-end not implemented yet.
rdar://12470317

llvm-svn: 166433

Fix by Shivarama Rao <Shivarama.Rao@amd.com>

llvm-svn: 166427

llvm-svn: 166425

llvm-svn: 166424

Unreachable blocks can have invalid instructions. For example,
jump threading can produce self-referential instructions in
unreachable blocks. Also, we should not be spending time
optimizing unreachable code. Fixes PR14133.

llvm-svn: 166423

Patch by Quentin Colombet <qcolombet@apple.com>

Original description:
"""
The attached patch is the first step to have a better control on Oz related optimizations.
The Oz optimization level focuses on code size, thus I propose to add an attribute called ForceSizeOpt.
"""

llvm-svn: 166422

llvm-svn: 166410

Vectorizer: optimize the generation of selects. If the condition is uniform, generate a scalar-cond select (i1 as selector).

llvm-svn: 166409

llvm-svn: 166408

very small but very important bugfix:
  bool shouldExplore(Use *U) {
    Value *V = U->get();
    if (isa<CallInst>(V) || isa<InvokeInst>(V))
    [...]
should have read:
  bool shouldExplore(Use *U) {
    Value *V = U->getUser();
    if (isa<CallInst>(V) || isa<InvokeInst>(V))
Fixes PR14143!

llvm-svn: 166407

It broke selfhosting stage2 in several builders.

llvm-svn: 166406

calls can be marked tail.

llvm-svn: 166405

This is important for vectors of pointers because only DataLayout,
not the underlying vector type, knows how to calculate the size
of the pointers in the vector. Fixes PR14138.

llvm-svn: 166401

It passes all tests, produces better results than the old code but uses the
wrong pass, LoopDependenceAnalysis, which is old and unmaintained. "Why is it
still in tree?", you might ask. The answer is obviously: "To confuse developers."

Just swapping in the new dependency pass sends the pass manager into an infinte
loop, I'll try to figure out why tomorrow.

llvm-svn: 166399

Reported by Vincent Lejeune using an out-of-tree target.

llvm-svn: 166398

llvm-svn: 166395

llvm-svn: 166393

llvm-svn: 166392

Requires a lot less code and complexity on loop-idiom's side and the more
precise analysis can catch more cases, like the one I included as a test case.
This also fixes the edge-case miscompilation from PR9481. I'm not entirely
sure that all cases are handled that the old checks handled but LDA will
certainly become smarter in the future.

llvm-svn: 166390

We used a SCEV to detect that A[X] is consecutive. We assumed that X was
the induction variable. But X can be any expression that uses the induction
for example: X = i + 2;

llvm-svn: 166388

This is important for nested-loop reductions such as :

In the innermost loop, the induction variable does not start with zero:

for (i = 0 .. n)
 for (j = 0 .. m)
  sum += ...

llvm-svn: 166387

llvm-svn: 166386

llvm-svn: 166384

rather than "$src = $dst").

llvm-svn: 166382

PR14134.

llvm-svn: 166379

obvious stuff and most new code being committed conforms to that.  Some old
code does not; this might cause confusion and this is the motivation to
document the correct guidelines.

llvm-svn: 166378

llvm-svn: 166376

llvm-svn: 166375

InstCombine: Fix an edge case where constant icmps could sneak into ConstantFoldInstOperands and crash.

Have to refactor the ConstantFolder interface one day to define bugs like this away. Fixes PR14131.

llvm-svn: 166374

If the pointer is consecutive then it is safe to read and write. If the pointer is non-loop-consecutive then
it is unsafe to vectorize it because we may hit an ordering issue.

llvm-svn: 166371

llvm-svn: 166367

llvm-svn: 166366

llvm-svn: 166364

[ms-inline asm] Rename AsmOpRewrite to just AsmRewrite to be more generic. No functional change intended.

llvm-svn: 166360

inline assembly.  Also make sure the remove the ignored statements from the IR.

llvm-svn: 166357

llvm-svn: 166354

llvm-svn: 166352