change hacks off 10K of bytecode from perlbmk (.5%) even though the front-end
is not generating them yet and we are not optimizing the resultant code.
This isn't too bad.

llvm-svn: 17111

llvm-svn: 17110

occurs in the entry node of a function

llvm-svn: 17109

exercise that I'm not interested in tackling right now.  Just punt and treat them
like unwind's.

This 'fixes' test/Regression/Transforms/ADCE/unreachable-function.ll

llvm-svn: 17106

other blocks.

llvm-svn: 17099

so prepare for this.

llvm-svn: 17095

llvm-svn: 17069

llvm-svn: 17067

ugly and giant constnat exprs in some programs.

llvm-svn: 17066

llvm-svn: 17047

ignore unreachable instructions

llvm-svn: 17044

llvm-svn: 17043

llvm-svn: 16950

llvm-svn: 16932

marker from one ilist into the middle of another basic block!

llvm-svn: 16925

pointer recurrences into expressions from this:

  %P_addr.0.i.0 = phi sbyte* [ getelementptr ([8 x sbyte]* %.str_1, int 0, int 0), %entry ], [ %inc.0.i, %no_exit.i ]
  %inc.0.i = getelementptr sbyte* %P_addr.0.i.0, int 1            ; <sbyte*> [#uses=2]

into this:

  %inc.0.i = getelementptr sbyte* getelementptr ([8 x sbyte]* %.str_1, int 0, int 0), int %inc.0.i.rec

Actually create something nice, like this:

  %inc.0.i = getelementptr [8 x sbyte]* %.str_1, int 0, int %inc.0.i.rec

llvm-svn: 16924

llvm-svn: 16918

llvm-svn: 16893

-debug-only!

llvm-svn: 16868

llvm-svn: 16863

254.gap.

llvm-svn: 16853

This comes up when doing adds to bitfield elements.

llvm-svn: 16836

This triggers in cases of bitfield additions, opening opportunities for
future improvements.

llvm-svn: 16834

llvm-svn: 16769

an instruction if it can be hoisted to a common dominator of the block.
This implements: test/Regression/Transforms/TailDup/MergeTest.ll

llvm-svn: 16758

llvm-svn: 16598

* SubOne/AddOne functions always return ConstantInt, declare them as such
* Pull code for handling setcc X, cst, where cst is at the end of the range,
  or cc is LE or GE up earlier in visitSetCondInst.  This reduces #iterations
  in some cases.
* Fold: (div X, C1) op C2 -> range check, implementing div.ll:test6 - test9.

llvm-svn: 16588

This takes something like this:

%A = phi int [ 3, %cond_false.0 ], [ 2, %endif.0.i ], [ 2, %endif.1.i ]
%B = div int %tmp.243, 4

and turns it into:

%A = phi int [ 3/4, %cond_false.0 ], [ 2/4, %endif.0.i ], [ 2/4, %endif.1.i ]

which is later simplified (in this case) into %A = 0.

This triggers thousands of times in spec, for example, 269 times in 176.gcc.

This is tested by InstCombine/add.ll:test23 and set.ll:test18.

llvm-svn: 16582

llvm-svn: 16568

Instcombine (setcc (truncate X), C1).

This occurs THOUSANDS of times in many benchmarks.  Particularlly common
seem to be things like (seteq (cast bool X to int), int 0)

This turns it into (seteq bool %X, false), which then becomes (not %X).

llvm-svn: 16567

This implements or.ll:test1[89]

llvm-svn: 16561

This is important for several reasons:

1. Benchmarks have lots of code that looks like this (perlbmk in particular):

  %tmp.2.i = setne int %tmp.0.i, 128              ; <bool> [#uses=1]
  %tmp.6343 = seteq int %tmp.0.i, 1               ; <bool> [#uses=1]
  %tmp.63 = and bool %tmp.2.i, %tmp.6343          ; <bool> [#uses=1]

   we now fold away the setne, a clear improvement.

2. In the more important cases, such as (X >= 10) & (X < 20), we now produce
   smaller code: (X-10) < 10.

3. Perhaps the nicest effect of this patch is that it really helps out the
   code generators.  In particular, for a 'range test' like the above,
   instead of generating this on X86 (the difference on PPC is even more
   pronounced):

        cmp %EAX, 50
        setge %CL
        cmp %EAX, 100
        setl %AL
        and %CL, %AL
        cmp %CL, 0

   we now generate this:

        add %EAX, -50
        cmp %EAX, 50

   Furthermore, this causes setcc's to be folded into branches more often.

These combinations trigger dozens of times in the spec benchmarks, particularly
in 176.gcc, 186.crafty, 253.perlbmk, 254.gap, & 099.go.

llvm-svn: 16559

Implement (setcc (shl X, C1), C2) folding.

The second one occurs several dozen times in spec.  The first was added
just in case.  :)

These are tested by shift.ll:test2[12], and div.ll:test5

llvm-svn: 16549

This latent bug was exposed by recent changes, and is tested as:
llvm/test/Regression/Transforms/InstCombine/2004-09-28-BadShiftAndSetCC.llx

llvm-svn: 16546

compile under windows. Patch contributed by Paolo Invernizzi!

llvm-svn: 16534

where we folded (X & 254) -> X < 1 instead of X < 2.  These problems were
latent problems exposed by the latest patch.

llvm-svn: 16528

triggers often, for example:

6x in povray, 1x in gzip, 279x in gcc, 1x in crafty, 8x in eon, 11x in perlbmk,
362x in gap, 4x in vortex, 14 in m88ksim, 211x in 126.gcc, 1x in compress,
11x in ijpeg, and 4x in 147.vortex.

llvm-svn: 16521

These combinations trigger 4 times in povray, 7x in gcc, 4x in gap, and 2x in bzip2.

llvm-svn: 16508

No functionality changes here.

llvm-svn: 16505

in perlbmk

llvm-svn: 16504