No functional change.

llvm-svn: 124257

llvm-svn: 124245

llvm-svn: 124233

appropriately so that it prints out the decimal representation.

llvm-svn: 124230

encoding. It's up to the individual back-ends to convert it to their preferred
representation when printing.

llvm-svn: 124229

llvm-svn: 124209

Resolve DanglingDbgValue of PHI nodes where the use follows dbg.value intrinisic.

llvm-svn: 124203

This assertion is too restrictive, it does not apply for dangling dbg value nodes (nodes where dbg.value intrinsic preceds use of the value). 

llvm-svn: 124202

llvm-svn: 124188

llvm-svn: 124184

optimized code are:
  (non-negative number)+(power-of-two) != 0 -> true
and
  (x | 1) != 0 -> true
Instcombine knows about the second one of course, but only does it if X|1
has only one use.  These fire thousands of times in the testsuite.

llvm-svn: 124183

for now. It's controlled by the HasGlobalAliases variable which is not attached
to any flag yet.

llvm-svn: 124182

rather than interspersed. No functional change.

llvm-svn: 124168

llvm-svn: 124167

llvm-svn: 124151

llvm-svn: 124150

llvm-svn: 124142

llvm-svn: 124138

rdar://problem/8893967

llvm-svn: 124137

with BasicAA's DecomposeGEPExpression, which recently began
using a TargetData. This fixes PR8968, though the testcase
is awkward to reduce.

Also, update several off GetUnderlyingObject's users
which happen to have a TargetData handy to pass it in.

llvm-svn: 124134

llvm-svn: 124132

* If the name is a single string, we remove the quotes
* If the name starts without a quote, we include any quotes in the name

llvm-svn: 124127

llvm-svn: 124126

llvm-svn: 124124

llvm-svn: 124102

code.

llvm-svn: 124100

llvm-svn: 124099

llvm-svn: 124097

define i32 @foo(i32 %x) nounwind readnone ssp {
entry:
  %tobool = icmp eq i32 %x, 0
  %tmp5 = select i1 %tobool, i32 2, i32 1
  ret i32 %tmp5
}

llvm-svn: 124091

occurs because instcombine sinks loads and inserts phis.  This kicks in 
on such apps as 175.vpr, eon, 403.gcc, xalancbmk and a bunch of times in
spec2006 in some app that uses std::deque.

This resolves the last of rdar://7339113.

llvm-svn: 124090

common cases.  This triggers a surprising number of times in SPEC2K6
because min/max idioms end up doing this.  For example, code from the
STL ends up looking like this to SRoA:

  %202 = load i64* %__old_size, align 8, !tbaa !3
  %203 = load i64* %__old_size, align 8, !tbaa !3
  %204 = load i64* %__n, align 8, !tbaa !3
  %205 = icmp ult i64 %203, %204
  %storemerge.i = select i1 %205, i64* %__n, i64* %__old_size
  %206 = load i64* %storemerge.i, align 8, !tbaa !3

We can now promote both the __n and the __old_size allocas.

This addresses another chunk of rdar://7339113, poor codegen on
stringswitch.

llvm-svn: 124088

dereferencable, noticed by inspection.

llvm-svn: 124085

llvm-svn: 124082

robust against smarter optimizations, using the power of FileCheck.

llvm-svn: 124081

llvm-svn: 124079

llvm-svn: 124077

clang's -Wuninitialized-experimental warning.
While these don't look like real bugs, clang's
-Wuninitialized-experimental analysis is stricter
than GCC's, and these fixes have the benefit
of being general nice cleanups.

llvm-svn: 124073

llvm-svn: 124071

that have PHI or select uses of their element pointers.  This can often happen
when instcombine sinks two loads into a successor, inserting a phi or select.

With this patch, we can scalarize the alloca, but the pinned elements are not
yet promoted.  This is still a win for large aggregates where only one element
is used.  This fixes rdar://8904039 and part of rdar://7339113 (poor codegen
on stringswitch).

llvm-svn: 124070

on test-suite + SPEC2000 & SPEC2006.

llvm-svn: 124068