llvm-svn: 16572

llvm-svn: 16571

of FMOVS instrs.

llvm-svn: 16570

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

integers that we can use as immediate values in instructions.

Example from yacr2:
-       lis r10, -1
-       ori r10, r10, 65535
-       add r28, r28, r10
+       addi r28, r28, -1
        addi r7, r7, 1
        addi r9, r9, 1
        b .LBB_main_9   ; loopentry.1.i214

llvm-svn: 16566

problems.

Patch contributed by Jeff Cohen. Thanks Jeff!

llvm-svn: 16565

Patch contributed by Jeff Cohen. Thanks Jeff!

llvm-svn: 16564

Patch contributed by Jeff Cohen. Thanks Jeff!

llvm-svn: 16563

Patch kindly contributed by Jeff Cohen. Thanks Jeff!

llvm-svn: 16562

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

llvm-svn: 16555

llvm-svn: 16551

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

llvm-svn: 16542

compile on windows. This patch was contributed by Paolo Invernizzi.

llvm-svn: 16539

llvm-svn: 16536

compilation problem in windows.

llvm-svn: 16535

compile under windows. Patch contributed by Paolo Invernizzi!

llvm-svn: 16534

llvm-svn: 16533

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

llvm-svn: 16528

llvm-svn: 16526

end of files, breaking the CFE build.  As a gross hack around this,
ignore any trailing garbage on bytecode files.  Thanks to Brian for digging
in and identifying the problem.

llvm-svn: 16525

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

llvm-svn: 16519

llvm-svn: 16518

llvm-svn: 16515

llvm-svn: 16513

llvm-svn: 16512

llvm-svn: 16511

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

llvm-svn: 16499

llvm-svn: 16495

the ISel to use indexed and non-zero immediate offsets for GEPs that have
more than one use.  This is common for instruction sequences such as a load
followed by a modify and store to the same address.

llvm-svn: 16493

llvm-svn: 16485

llvm-svn: 16484