LLVM CFG when trying to find the successors of BB.

llvm-svn: 13212

llvm-svn: 13211

llvm-svn: 13204

patch was graciously contributed by Vladimir Prus.

llvm-svn: 13185

renamed since they were last spiffed up, or they just never had proper comments
in the first place.

llvm-svn: 13148

llvm-svn: 13147

Include SparcV9RegisterInfo.h.
Add a getRegisterInfo() accessor and SparcV9RegisterInfo instance, just like
on the X86 target.

llvm-svn: 13146

functions for now). This automatically turns on the printing of machine
registers using their own real names, instead of goofy things like %mreg(42),
and allows us to migrate code incrementally to the new interface as we see fit.

The register file description it uses is hand-written, so that the register
numbers will match the ones that the SparcV9 target already uses.
Perhaps someday we'll tablegen it.

llvm-svn: 13145

llvm-svn: 13136

This prepares us to be able to de-virtualize and de-abstract it, and
take the register allocator bits out and move them into the register allocator
proper...

llvm-svn: 13127

llvm-svn: 13126

being tested on X86, as per Chris's request.

llvm-svn: 13124

llvm-svn: 13120

Use emitWordAt() to emit forward-branch fixups.

llvm-svn: 13119

of IntCC, FloatCC, and Special types.

Make SparcV9RegInfo::getRegClassIDOfRegType() return the right answer
if you ask for the class corresponding to SpecialRegType.

llvm-svn: 13095

llvm-svn: 13078

llvm-svn: 13073

llvm-svn: 13071

the name of %fsr (as the comment in SparcV9RegClassInfo.h used to suggest)
you would walk off the end of the FloatCCRegName array.

llvm-svn: 13070

Remove the extra %fsr register from SparcV9FloatCCRegClass.

llvm-svn: 13069

llvm-svn: 12967

The iterator is pointing at the next instruction which should not disappear
when doing the load/store replacement.

llvm-svn: 12954

llvm-svn: 12953

even when the "optimization" I added before is turned off.  It generates this
extremely pointless code:

test:
        fld QWORD PTR [%ESP + 4]
        mov %AL, 0
        test %AL, %AL
        fcmove %ST(0), %ST(0)
        ret

Good thing the optimizer will have removed this before code generation
anyway.  :)

llvm-svn: 12939

On x86, memory operations occur in-order, so these are just lowered into
volatile loads and stores.

llvm-svn: 12936

X86/2004-04-13-FPCMOV-Crash.llx

A more robust fix is to follow.

llvm-svn: 12935

llvm-svn: 12905

llvm-svn: 12903

Fix several bugs in the intrinsics:
  1. Make sure to copy the input registers before the instructions that use them
  2. Make sure to copy the value returned by 'in' out of EAX into the register
     it is supposed to be in.

This fixes assertions when using in/out and linear scan.

llvm-svn: 12896

llvm-svn: 12895

llvm-svn: 12894

llvm-svn: 12893

llvm-svn: 12874

llvm-svn: 12855

I have unsaved emacs buffers, geeze...

llvm-svn: 12854

llvm-svn: 12853

of the fucom[p][p] instructions.  This allows us to code generate this function

bool %test(double %X, double %Y) {
        %C = setlt double %Y, %X
        ret bool %C
}

... into:

test:
        fld QWORD PTR [%ESP + 4]
        fld QWORD PTR [%ESP + 12]
        fucomip %ST(1)
        fstp %ST(0)
        setb %AL
        movsx %EAX, %AL
        ret

where before we generated:

test:
        fld QWORD PTR [%ESP + 4]
        fld QWORD PTR [%ESP + 12]
        fucompp
**      fnstsw
**      sahf
        setb %AL
        movsx %EAX, %AL
        ret

The two marked instructions (which are the ones eliminated) are very bad,
because they serialize execution of the processor.  These instructions are
available on the PPRO and later, but since we already use cmov's we aren't
losing any portability.

I retained the old code for the day when we decide we want to support back
to the 386.

llvm-svn: 12852

llvm-svn: 12851

llvm-svn: 12850

llvm-svn: 12849