This is needed so debug info doesn't change codegen.

llvm-svn: 66235

llvm-svn: 66233

We are still not out of woods yet.

llvm-svn: 66232

llvm-svn: 66227

debug intrinsics correctly.

llvm-svn: 66225

llvm-svn: 66224

llvm-svn: 66223

If non constant local GV named A is used by a constant local GV named B (e.g. llvm.dbg.variable) and B is not used by anyone else then eliminate A as well as B.

In other words, debug info should not interfere in removal of unused GV.
--This life, and those below, will be ignored--

M    test/Transforms/GlobalOpt/2009-03-03-dbg.ll
M    lib/Transforms/IPO/GlobalOpt.cpp

llvm-svn: 66167

llvm-svn: 66140

codegen.  I convinced myself it was OK to skip all
pointer bitcasts here too.

llvm-svn: 66122

llvm-svn: 66115

had 2 uses instead of 1.

llvm-svn: 66112

llvm-svn: 66083

was causing llvm-gcc to fail to build.  I've
verified it bootstraps now; good enough for me.

llvm-svn: 66073

llvm-svn: 66065

immediately obvious.

llvm-svn: 66062

llvm-svn: 66055

llvm-svn: 66054

onto element accesses.

llvm-svn: 66053

llvm-svn: 66001

llvm-svn: 66000

per Chris' suggestion.  Slightly faster.

llvm-svn: 65999

If a global constant is dead then global's debug info should not prevent the optimizer in deleting the global. And while deleting global, delete global's debug info also.

llvm-svn: 65994

when counting work; it was only off by 1.

llvm-svn: 65993

caused them to be considered trivially dead.  Fix this.

llvm-svn: 65979

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

llvm-svn: 65976

llvm-svn: 65971

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: 65961

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

llvm-svn: 65908

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

This is ugly, but I can't figure out a quick way out of this.

llvm-svn: 65889

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