immediately obvious.

llvm-svn: 66062

llvm-svn: 66055

llvm-svn: 66054

onto element accesses.

llvm-svn: 66053

per Chris' suggestion.  Slightly faster.

llvm-svn: 65999

when counting work; it was only off by 1.

llvm-svn: 65993

feed into llvm.dbg.declare nodes, as well as
the debug directives themselves.

llvm-svn: 65976

use, check also for the case where it has two uses,
the other being a llvm.dbg.declare.  This is needed so
debug info doesn't affect codegen.

llvm-svn: 65970

llvm-svn: 65960

llvm-svn: 65945

and put @file directives on their own comment line.

llvm-svn: 65920

(lest they affect codegen).

llvm-svn: 65915

info with it.
Don't count debug info insns against the scan maximum
in FindAvailableLoadedValue (lest they affect codegen).

llvm-svn: 65910

If branch conditions' one successor is dominating another non-latch successor then this loop's iteration space can not be restricted. In this example block bb5 is always executed.

llvm-svn: 65902

clean up when using variable length arrays in llvm-gcc.

llvm-svn: 65832

testsuite:

Running /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/CodeGen/X86/dg.exp ...
FAIL: /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/CodeGen/X86/nancvt.ll
Failed with exit(1) at line 2
while running: grep 2147027116 nancvt.ll.tmp | count 3
count: expected 3 lines and got        0.
child process exited abnormally
FAIL: /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/CodeGen/X86/vec_ins_extract.ll
Failed with exit(1) at line 1
while running:  llvm-as < /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/CodeGen/X86/vec_ins_extract.ll |  opt -scalarrepl -instcombine |   llc -march=x86 -mcpu=yonah | not /usr/bin/grep sub.*esp
      subl      $28, %esp
      subl      $28, %esp
child process exited abnormally

And more.

llvm-svn: 65758

as well as isSafeAllocaToScalarRepl.

llvm-svn: 65755

are always set by reference on the path that uses them.) No functional change.

llvm-svn: 65621

llvm-svn: 65464

to more accurately describe what it does. Expand its doxygen comment
to describe what the backedge-taken count is and how it differs
from the actual iteration count of the loop. Adjust names and
comments in associated code accordingly.

llvm-svn: 65382

ashr instcombine to help expose this code. And apply the fix to
SelectionDAG's copy of this code too.

llvm-svn: 65364

handling non-constant strides. No functionality change.

llvm-svn: 65363

llvm-svn: 65359

trip counts that use signed comparisons. It's not obviously the best
approach for preserving trip count information, and at any rate there
isn't anything in the tree right now that makes use of that, so for
now always using zero-extensions is preferable.

llvm-svn: 65347

so that ScalarEvolution doesn't hang onto a dangling Loop*, which
could be a problem if another Loop happens to get allocated at the
same address.

llvm-svn: 65323

-std-compile-opts sequence, this avoids the need for ScalarEvolution to
be rerun before LoopDeletion.

llvm-svn: 65318

llvm-svn: 65314

llvm-svn: 65306

memcpy to match the alignment of the destination. It isn't necessary
for making loads and stores handled like the SSE loadu/storeu
intrinsics, and it was causing a performance regression in
MultiSource/Applications/JM/lencod.

The problem appears to have been a memcpy that copies from some
highly aligned array into an alloca; the alloca was then being
assigned a large alignment, which required codegen to perform
dynamic stack-pointer re-alignment, which forced the enclosing
function to have a frame pointer, which led to increased spilling.

llvm-svn: 65289

-full-lsr code, as well as a GCC warning.

llvm-svn: 65288

Only try to sink immediate when TLI is not null. It needs to check if immediate would fit in target addressing field.

llvm-svn: 65268

load(bitcast(char[4] to i32*)) evaluation.

llvm-svn: 65246

Teach LSR sink to sink the immediate portion of the common expression back into uses if they fit in address modes of all the uses.

llvm-svn: 65215

as legality.  Make load sinking and gep sinking more careful: we only
do it when it won't pessimize loads from the stack.  This has the added
benefit of not producing code that is unanalyzable to SROA.

llvm-svn: 65209

addresses, part 1. This fixes an obvious logic bug. Previously if the only
in-loop use is a PHI, it would return AllUsesAreAddresses as true.

llvm-svn: 65178

llvm-svn: 65167

llvm-svn: 65159

llvm-svn: 65157

llvm-svn: 65147

Factor address mode matcher out of codegen prepare to make it available to other passes, e.g. loop strength reduction.

llvm-svn: 65134