global with an alloca, which eventually gets promoted into a
register. This enables a lot of other optimizations later on.

llvm-svn: 20109

llvm-svn: 19988

llvm-svn: 19959

llvm-svn: 19958

llvm-svn: 19957

in spec

llvm-svn: 19953

llvm-svn: 19950

11 indirect calls in perlbmk.

llvm-svn: 19947

llvm-svn: 19900

llvm-svn: 19899

llvm-svn: 19898

llvm-svn: 19897

* Properly compile this:

struct a {};
int test() {
  struct a b[2];
  if (&b[0] != &b[1])
    abort ();
  return 0;
}

to 'return 0', not abort().

llvm-svn: 19875

automatically.

llvm-svn: 19828

llvm-svn: 19786

as long as they are the same size.

llvm-svn: 19734

The second folds operations into selects, e.g. (select C, (X+Y), (Y+Z))
-> (Y+(select C, X, Z)

This occurs a few times across spec, e.g.

         select    add/sub
mesa:    83        0
povray:  5         2
gcc      4         2
parser   0         22
perlbmk  13        30
twolf    0         3

llvm-svn: 19706

llvm-svn: 19693

useness.

llvm-svn: 19629

Disable the xform for < > cases.  It turns out that the following is being
miscompiled:

bool %test(sbyte %S) {
        %T = cast sbyte %S to uint
        %V = setgt uint %T, 255
        ret bool %V
}

llvm-svn: 19628

llvm-svn: 19553

llvm-svn: 19552

This allows us to better optimize begin() -> end() comparisons in common cases.

llvm-svn: 19542

llvm-svn: 19541

the 'sim' program and probably elsewhere.  In sim, it comes up for cases
like this:

#define round(x) ((x)>0.0 ? (x)+0.5 : (x)-0.5)
double G;
void T(double X) { G = round(X); }

(it uses the round macro a lot).  This changes the LLVM code from:

        %tmp.1 = setgt double %X, 0.000000e+00          ; <bool> [#uses=1]
        %tmp.4 = add double %X, 5.000000e-01            ; <double> [#uses=1]
        %tmp.6 = sub double %X, 5.000000e-01            ; <double> [#uses=1]
        %mem_tmp.0 = select bool %tmp.1, double %tmp.4, double %tmp.6
        store double %mem_tmp.0, double* %G

to:

        %tmp.1 = setgt double %X, 0.000000e+00          ; <bool> [#uses=1]
        %mem_tmp.0.p = select bool %tmp.1, double 5.000000e-01, double -5.000000e-01
        %mem_tmp.0 = add double %mem_tmp.0.p, %X
        store double %mem_tmp.0, double* %G
        ret void

llvm-svn: 19537

_Bool test2(int X, int Y) {
  return &arr[X][Y] == arr;
}

instead of generating this:

bool %test2(int %X, int %Y) {
        %tmp.3.idx = mul int %X, 160            ; <int> [#uses=1]
        %tmp.3.idx1 = shl int %Y, ubyte 2               ; <int> [#uses=1]
        %tmp.3.offs2 = sub int 0, %tmp.3.idx            ; <int> [#uses=1]
        %tmp.7 = seteq int %tmp.3.idx1, %tmp.3.offs2            ; <bool> [#uses=1]
        ret bool %tmp.7
}


generate this:

bool %test2(int %X, int %Y) {
        seteq int %X, 0         ; <bool>:0 [#uses=1]
        seteq int %Y, 0         ; <bool>:1 [#uses=1]
        %tmp.7 = and bool %0, %1                ; <bool> [#uses=1]
        ret bool %tmp.7
}

This idiom occurs in C++ programs when iterating from begin() to end(),
in a vector or array.  For example, we now compile this:

void test(int X, int Y) {
  for (int *i = arr; i != arr+100; ++i)
    foo(*i);
}

to this:

no_exit:                ; preds = %entry, %no_exit
	...
        %exitcond = seteq uint %indvar.next, 100                ; <bool> [#uses=1]
        br bool %exitcond, label %return, label %no_exit



instead of this:

no_exit:                ; preds = %entry, %no_exit
	...
        %inc5 = getelementptr [100 x [40 x int]]* %arr, int 0, int 0, int %inc.rec              ; <int*> [#uses=1]
        %tmp.8 = seteq int* %inc5, getelementptr ([100 x [40 x int]]* %arr, int 0, int 100, int 0)              ; <bool> [#uses=1]
        %indvar.next = add uint %indvar, 1              ; <uint> [#uses=1]
        br bool %tmp.8, label %return, label %no_exit

llvm-svn: 19536

llvm-svn: 19534

llvm-svn: 19533

intended to be a dlopenable module and not a "plain" shared library.

llvm-svn: 19456

llvm-svn: 19432

llvm-svn: 19383

llvm-svn: 19382

llvm-svn: 19381

llvm-svn: 19380

llvm-svn: 19379

llvm-svn: 19370

llvm-svn: 19320

llvm-svn: 19319

llvm-svn: 19315

llvm-svn: 19306