186.crafty, fhourstones and 132.ijpeg.

Bugpoint makes really nasty miscompilations embarassingly easy to find.  It
narrowed it down to the instcombiner and this testcase (from fhourstones):

bool %l7153_l4706_htstat_loopentry_2E_4_no_exit_2E_4(int* %i, [32 x int]* %works, int* %tmp.98.out) {
newFuncRoot:
        %tmp.96 = load int* %i          ; <int> [#uses=1]
        %tmp.97 = getelementptr [32 x int]* %works, long 0, int %tmp.96         ; <int*> [#uses=1]
        %tmp.98 = load int* %tmp.97             ; <int> [#uses=2]
        %tmp.99 = load int* %i          ; <int> [#uses=1]
        %tmp.100 = and int %tmp.99, 7           ; <int> [#uses=1]
        %tmp.101 = seteq int %tmp.100, 7                ; <bool> [#uses=2]
        %tmp.102 = cast bool %tmp.101 to int            ; <int> [#uses=0]
        br bool %tmp.101, label %codeRepl4.exitStub, label %codeRepl3.exitStub

codeRepl4.exitStub:             ; preds = %newFuncRoot
        store int %tmp.98, int* %tmp.98.out
        ret bool true

codeRepl3.exitStub:             ; preds = %newFuncRoot
        store int %tmp.98, int* %tmp.98.out
        ret bool false
}

... which only has one combination performed on it:

$ llvm-as < t.ll | opt -instcombine -debug | llvm-dis
IC: Old =       %tmp.101 = seteq int %tmp.100, 7                ; <bool> [#uses=1]
    New =       setne int %tmp.100, 0           ; <bool>:<badref> [#uses=0]
IC: MOD =       br bool %tmp.101, label %codeRepl3.exitStub, label %codeRepl4.exitStub
IC: MOD =       %tmp.97 = getelementptr [32 x int]* %works, uint 0, int %tmp.96         ; <int*> [#uses=1]

It doesn't get much better than this.  :)

llvm-svn: 14109

llvm-svn: 14108

llvm-svn: 14107

llvm-svn: 14106

llvm-svn: 14104

llvm-svn: 14103

llvm-svn: 14102

llvm-svn: 14101

on new front-ends and stuff).  Also get rid of some tabs that snuck in.

llvm-svn: 14100

such a way that if the Value being printed is standalone that we don't
assert and abort but just print ":??" for the slot number instead.

llvm-svn: 14097

that cast to bool.

llvm-svn: 14096

llvm-svn: 14095

llvm-svn: 14093

llvm-svn: 14091

llvm-svn: 14090

Don't dump functions unless "detailedResults" is requested.

llvm-svn: 14089

llvm-svn: 14088

llvm-svn: 14087

collapse this:
bool %le(int %A, int %B) {
        %c1 = setgt int %A, %B
        %tmp = select bool %c1, int 1, int 0
        %c2 = setlt int %A, %B
        %result = select bool %c2, int -1, int %tmp
        %c3 = setle int %result, 0
        ret bool %c3
}

into:

bool %le(int %A, int %B) {
        %c3 = setle int %A, %B          ; <bool> [#uses=1]
        ret bool %c3
}

which is handy, because the Java FE makes these sequences all over the place.

This is tested as: test/Regression/Transforms/InstCombine/JavaCompare.ll

llvm-svn: 14086

in doxygen.

llvm-svn: 14084

llvm-svn: 14083

llvm-svn: 14078

This fixes PR363

llvm-svn: 14076

accounted for in the map (at least, in its current format).

llvm-svn: 14075

llvm-svn: 14073

llvm-svn: 14071

files. It was reading non-initialized global vars when the flag said it was
initialized and vice versa. Causes mis-alignment since initialized and
non-initialized constants have different bytecode lengths.

llvm-svn: 14057

needs the BytecodeHandler interface which is now in Parser.h

llvm-svn: 14056

llvm-svn: 14055

must always coexist. Cleaned up the documentation on these interfaces
significantly. This is in preparation for moving Parser.h to the include
directories to make it a public interface.

llvm-svn: 14054

Dominance properties don't hold in unreachable code

llvm-svn: 14053

system specific stuff on HAVE_MKSTEMP

llvm-svn: 14051

getrusage implementation on HAVE_GETRUSAGE

llvm-svn: 14050

will (eventually) provide statistical analysis of bytecode files as well
as the ability to dump them in a low level format (slot numbers not
resolved). The purpose of this is to aid in the Type!=Value change of
bug 122. With this initial release, llvm-abcd merely dumps out the
bytecode. However, the infrastructure for separating bytecode parsing from
handling the parsing events is in place. The style chosen is similar to
SAX XML parsing where a handler object is called to handlign the parsing
events. This probably isn't useful to anyone but me right now as there is
no analysis yet, and the dumper doesn't work on every bytecode file. It
will probably be useful by the end of this week. Note that there is some
duplication of code from the bytecode reader.  This was done to eliminate
errors from being introduced in the reader and to minimize the impact to
other LLVM developers. At some point, the Analyzer and the Reader will be
integrated to use the same infrastructure. Also, sorry for the minor change
to Instruction.h but I just couldn't bring myself to write code that
depends on Instruction internals.

llvm-svn: 14048

llvm-svn: 14046

llvm-svn: 14045

llvm-svn: 14044

llvm-svn: 14041

Work around for bogus errors: no those static functions don't need to
be executed to be initialized!

llvm-svn: 14040

llvm-svn: 14037