| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
allows us to compile:
store float 10.0, float* %P
into:
mov DWORD PTR [%EAX], 1092616192
instead of:
.CPItest_0: # float 0x4024000000000000
.long 1092616192 # float 10
...
fld DWORD PTR [.CPItest_0]
fstp DWORD PTR [%EAX]
llvm-svn: 13409
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
against zero. In particular, don't emit:
mov %ESI, 0
cmp %ECX, %ESI
instead, emit:
test %ECX, %ECX
llvm-svn: 13407
|
| |
|
|
| |
llvm-svn: 13362
|
| |
|
|
|
|
|
|
|
| |
constant pool member's name.
This is intended to address Bug 333.
Also, fix an anachronistic usage of "M" as a parameter of type Function *.
llvm-svn: 13357
|
| |
|
|
| |
llvm-svn: 13355
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
div:
mov %EDX, DWORD PTR [%ESP + 4]
mov %ECX, 64
mov %EAX, %EDX
sar %EDX, 31
idiv %ECX
ret
to this:
div:
mov %EAX, DWORD PTR [%ESP + 4]
mov %ECX, %EAX
sar %ECX, 5
shr %ECX, 26
mov %EDX, %EAX
add %EDX, %ECX
sar %EAX, 6
ret
Note that the intel compiler is currently making this:
div:
movl 4(%esp), %edx #3.5
movl %edx, %eax #4.14
sarl $5, %eax #4.14
shrl $26, %eax #4.14
addl %edx, %eax #4.14
sarl $6, %eax #4.14
ret #4.14
Which has one less register->register copy. (hint hint alkis :)
llvm-svn: 13354
|
| |
|
|
| |
llvm-svn: 13342
|
| |
|
|
| |
llvm-svn: 13304
|
| |
|
|
|
|
| |
Look at all of the pretty minuses. :)
llvm-svn: 13303
|
| |
|
|
| |
llvm-svn: 13297
|
| |
|
|
| |
llvm-svn: 13291
|
| |
|
|
|
|
|
| |
In InsertFPRegKills(), just check the MachineBasicBlock for successors
instead of its corresponding BasicBlock.
llvm-svn: 13213
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
implicitly use ST(0)
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
|