- Mar 11, 2004
-
-
Misha Brukman authored
llvm-svn: 12289
-
- Mar 09, 2004
-
-
Alkis Evlogimenos authored
instructions. llvm-svn: 12258
-
Alkis Evlogimenos authored
llvm-svn: 12254
-
Alkis Evlogimenos authored
llvm-svn: 12253
-
Alkis Evlogimenos authored
llvm-svn: 12252
-
Alkis Evlogimenos authored
llvm-svn: 12251
-
- Mar 08, 2004
-
-
Chris Lattner authored
testcase like this: int %test(int* %P, int %A) { %Pv = load int* %P %B = add int %A, %Pv ret int %B } We now generate: test: mov %ECX, DWORD PTR [%ESP + 4] mov %EAX, DWORD PTR [%ESP + 8] add %EAX, DWORD PTR [%ECX] ret Instead of: test: mov %EAX, DWORD PTR [%ESP + 4] mov %ECX, DWORD PTR [%ESP + 8] mov %EAX, DWORD PTR [%EAX] add %EAX, %ECX ret ... saving one instruction, and often a register. Note that there are a lot of other instructions that could use this, but they aren't handled. I'm not really interested in adding them, but mul/div and all of the FP instructions could be supported as well if someone wanted to add them. llvm-svn: 12204
-
Chris Lattner authored
llvm-svn: 12203
-
- Mar 07, 2004
-
-
Alkis Evlogimenos authored
llvm-svn: 12190
-
- Mar 04, 2004
-
-
Brian Gaeke authored
llvm-svn: 12122
-
Alkis Evlogimenos authored
llvm-svn: 12120
-
- Mar 02, 2004
-
-
Misha Brukman authored
llvm-svn: 12064
-
- Mar 01, 2004
-
-
Brian Gaeke authored
(16) into certain areas of the SPARC V9 back-end. I'm fairly sure the US IIIi's dcache has 32-byte lines, so I'm not sure where the 16 came from. However, in the interest of not breaking things any more than they already are, I'm going to leave the constant alone. llvm-svn: 12043
-
Chris Lattner authored
of generating this code: mov %EAX, 4 mov DWORD PTR [%ESP], %EAX mov %AX, 123 movsx %EAX, %AX mov DWORD PTR [%ESP + 4], %EAX call Y we now generate: mov DWORD PTR [%ESP], 4 mov DWORD PTR [%ESP + 4], 123 call Y Which hurts the eyes less. :) Considering that register pressure around call sites is already high (with all of the callee clobber registers n stuff), this may help a lot. llvm-svn: 12028
-
Chris Lattner authored
to function calls, we would emit dead code, like this: int Y(int, short, double); int X() { Y(4, 123, 4); } --- Old X: sub %ESP, 20 mov %EAX, 4 mov DWORD PTR [%ESP], %EAX *** mov %AX, 123 mov %AX, 123 movsx %EAX, %AX mov DWORD PTR [%ESP + 4], %EAX fld QWORD PTR [.CPIX_0] fstp QWORD PTR [%ESP + 8] call Y mov %EAX, 0 # IMPLICIT_USE %EAX %ESP add %ESP, 20 ret Now we emit: X: sub %ESP, 20 mov %EAX, 4 mov DWORD PTR [%ESP], %EAX mov %AX, 123 movsx %EAX, %AX mov DWORD PTR [%ESP + 4], %EAX fld QWORD PTR [.CPIX_0] fstp QWORD PTR [%ESP + 8] call Y mov %EAX, 0 # IMPLICIT_USE %EAX %ESP add %ESP, 20 ret Next up, eliminate the mov AX and movsx entirely! llvm-svn: 12026
-
- Feb 29, 2004
-
-
Alkis Evlogimenos authored
llvm-svn: 11998
-
Alkis Evlogimenos authored
operand size is correctly specified. llvm-svn: 11997
-
Alkis Evlogimenos authored
1) For 8-bit registers try to use first the ones that are parts of the same register (AL then AH). This way we only alias 2 16/32-bit registers after allocating 4 8-bit variables. 2) Move EBX as the last register to allocate. This will cause less spills to happen since we will have 8-bit registers available up to register excaustion (assuming we use the allocation order). It would be nice if we could push all of the 8-bit aliased registers towards the end but we much prefer to keep callee saved register to the end to avoid saving them on entry and exit of the function. For example this gives a slight reduction of spills with linear scan on 164.gzip. Before: 11221 asm-printer - Number of machine instrs printed 975 spiller - Number of loads added 675 spiller - Number of stores added 398 spiller - Number of register spills After: 11182 asm-printer - Number of machine instrs printed 952 spiller - Number of loads added 652 spiller - Number of stores added 386 spiller - Number of register spills llvm-svn: 11996
-
Alkis Evlogimenos authored
their names more decriptive. A name consists of the base name, a default operand size followed by a character per operand with an optional special size. For example: ADD8rr -> add, 8-bit register, 8-bit register IMUL16rmi -> imul, 16-bit register, 16-bit memory, 16-bit immediate IMUL16rmi8 -> imul, 16-bit register, 16-bit memory, 8-bit immediate MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory llvm-svn: 11995
-
Chris Lattner authored
Replace uses of addZImm with addImm. llvm-svn: 11992
-
Chris Lattner authored
block loops. llvm-svn: 11990
-
Chris Lattner authored
llvm-svn: 11987
-
Chris Lattner authored
llvm-svn: 11984
-
Alkis Evlogimenos authored
llvm-svn: 11974
-
Alkis Evlogimenos authored
to denote this fact. llvm-svn: 11972
-
Alkis Evlogimenos authored
denote this fact. llvm-svn: 11971
-
Alkis Evlogimenos authored
parse. The name is now I (operand size)*. For example: Im32 -> instruction with 32-bit memory operands. Im16i8 -> instruction with 16-bit memory operands and 8 bit immediate operands. llvm-svn: 11970
-
- Feb 28, 2004
-
-
Alkis Evlogimenos authored
operand but their sizes differ. llvm-svn: 11969
-
Alkis Evlogimenos authored
the size of the immediate and the memory operand on instructions that use them. This resolves problems with instructions that take both a memory and an immediate operand but their sizes differ (i.e. ADDmi32b). llvm-svn: 11967
-
Alkis Evlogimenos authored
operands. The X86 backend doesn't handle them properly right now. llvm-svn: 11944
-
Alkis Evlogimenos authored
llvm-svn: 11933
-
Alkis Evlogimenos authored
llvm-svn: 11932
-
Alkis Evlogimenos authored
an 8-bit immediate. So mark the shifts that take immediates as taking an 8-bit argument. The rest with the implicit use of CL are marked appropriately. A bug still exists: def SHLDmri32 : I2A8 <"shld", 0xA4, MRMDestMem>, TB; // [mem32] <<= [mem32],R32 imm8 The immediate in the above instruction is 8-bit but the memory reference is 32-bit. The printer prints this as an 8-bit reference which confuses the assembler. Same with SHRDmri32. llvm-svn: 11931
-
- Feb 27, 2004
-
-
Alkis Evlogimenos authored
instructions. llvm-svn: 11923
-
Alkis Evlogimenos authored
them so that they are consistent with AND, XOR, etc... llvm-svn: 11922
-
Alkis Evlogimenos authored
llvm-svn: 11921
-
Alkis Evlogimenos authored
instructions. llvm-svn: 11907
-
Alkis Evlogimenos authored
llvm-svn: 11905
-
Alkis Evlogimenos authored
llvm-svn: 11903
-
Alkis Evlogimenos authored
consistent with the rest and also pepare for the addition of their memory operand variants. llvm-svn: 11902
-