llvm-svn: 25957

llvm-svn: 25956

int %rlwnm(int %A, int %B) {
  %C = call int asm "rlwnm $0, $1, $2, $3, $4", "=r,r,r,n,n"(int %A, int %B, int 4, int 17)
  ret int %C
}

into:

_rlwnm:
        or r2, r3, r3
        or r3, r4, r4
        rlwnm r2, r2, r3, 4, 17    ;; note the immediates :)
        or r3, r2, r2
        blr

llvm-svn: 25955

llvm-svn: 25954

flag so it can be flagged to a FST.

llvm-svn: 25953

llvm-svn: 25952

llvm-svn: 25951

llvm-svn: 25950

llvm-svn: 25949

store EAX -> [ss#0]
[ss#0] += 1
...
use(EAX)

In this case, it is not valid to rewrite this as:


store EAX -> [ss#0]
EAX += 1
store EAX -> [ss#0]  ;;; this would also delete the store above
...
use(EAX)

... because EAX is not a dead at that point.  Keep track of which registers
we are allowed to clobber, and which ones we aren't, and don't clobber the
ones we're not supposed to.  :)

This should resolve the issues on X86 last night.

llvm-svn: 25948

and PhysRegsAvailable maps out into a new AvailableSpills struct.  No
functionality change.

This paves the way for a bugfix, coming up next.

llvm-svn: 25947

llvm-svn: 25946

llvm-svn: 25945

llvm-svn: 25944

llvm-svn: 25943

llvm-svn: 25942

llvm-svn: 25941

llvm-svn: 25940

obsolete.  yaay :)

llvm-svn: 25939

instruction when possible.

llvm-svn: 25938

X86 backend attempts to match small-immediate versions of instructions before
the full size immediate versions.

llvm-svn: 25937

Remove the dead getRegClassForType method
minor formating changes.

llvm-svn: 25936

llvm-svn: 25935

llvm-svn: 25934

llvm-svn: 25933

llvm-svn: 25932

Chain is initially set to the chain operand of store node, when it reaches
load, if it matches the load then Chain is set to the chain operand of the
load.

However, if the matching code that follows this fails, isel moves on to the
next pattern but it does not restore Chain to the chain operand of the store.
So when it tries to match the next store / op / load pattern it would fail on
the Chain == load.getOperand(0) test.

The solution is for each chain operand to get a unique name. e.g. Chain10.

llvm-svn: 25931

llvm-svn: 25930

llvm-svn: 25929

llvm-svn: 25928

a std::multimap iterator value.  For some reason, GCC doesn't have a problem with this.

llvm-svn: 25927

llvm-svn: 25926

llvm-svn: 25925

llvm-svn: 25924

llvm-svn: 25923

1. a target doesn't know how to fold load/stores into copies, or
2. the spiller rewrites the input to a copy to the same register as the dest
   instead of to the reloaded reg.

This will be moved/improved in the near future, but allows elimination of
some ancient x86 hacks.  This eliminates 92 copies from SMG2000 on X86 and
163 copies from 252.eon.

llvm-svn: 25922

llvm-svn: 25921

llvm-svn: 25920

of this, and use it to our advantage (bwahahah).  This allows us to eliminate another
60 instructions from smg2000 on PPC (probably significantly more on X86).  A common
old-new diff looks like this:

        stw r2, 3304(r1)
-       lwz r2, 3192(r1)
        stw r2, 3300(r1)
-       lwz r2, 3192(r1)
        stw r2, 3296(r1)
-       lwz r2, 3192(r1)
        stw r2, 3200(r1)
-       lwz r2, 3192(r1)
        stw r2, 3196(r1)
-       lwz r2, 3192(r1)
+       or r2, r2, r2
        stw r2, 3188(r1)

and

-       lwz r31, 604(r1)
-       lwz r13, 604(r1)
-       lwz r14, 604(r1)
-       lwz r15, 604(r1)
-       lwz r16, 604(r1)
-       lwz r30, 604(r1)
+       or r31, r30, r30
+       or r13, r30, r30
+       or r14, r30, r30
+       or r15, r30, r30
+       or r16, r30, r30
+       or r30, r30, r30

Removal of the R = R copies is coming next...

llvm-svn: 25919

llvm-svn: 25918