[llvm-commits] CVS: llvm/lib/Target/X86/README.txt
Nate Begeman
natebegeman at mac.com
Tue Aug 1 22:31:34 PDT 2006
Changes in directory llvm/lib/Target/X86:
README.txt updated: 1.122 -> 1.123
---
Log message:
Update the readme to remove duplicate information and clarify the loop
problem.
---
Diffs of the changes: (+20 -45)
README.txt | 65 ++++++++++++++++++-------------------------------------------
1 files changed, 20 insertions(+), 45 deletions(-)
Index: llvm/lib/Target/X86/README.txt
diff -u llvm/lib/Target/X86/README.txt:1.122 llvm/lib/Target/X86/README.txt:1.123
--- llvm/lib/Target/X86/README.txt:1.122 Wed Jul 26 16:49:52 2006
+++ llvm/lib/Target/X86/README.txt Wed Aug 2 00:31:20 2006
@@ -198,7 +198,7 @@
_test:
movl 8(%esp), %ebx
- xor %eax, %eax
+ xor %eax, %eax
cmpl %ebx, 4(%esp)
setl %al
ret
@@ -340,22 +340,6 @@
//===---------------------------------------------------------------------===//
-Investigate whether it is better to codegen the following
-
- %tmp.1 = mul int %x, 9
-to
-
- movl 4(%esp), %eax
- leal (%eax,%eax,8), %eax
-
-as opposed to what llc is currently generating:
-
- imull $9, 4(%esp), %eax
-
-Currently the load folding imull has a higher complexity than the LEA32 pattern.
-
-//===---------------------------------------------------------------------===//
-
We are currently lowering large (1MB+) memmove/memcpy to rep/stosl and rep/movsl
We should leave these as libcalls for everything over a much lower threshold,
since libc is hand tuned for medium and large mem ops (avoiding RFO for large
@@ -671,35 +655,26 @@
//===---------------------------------------------------------------------===//
-Consider:
-int foo(int *a, int t) {
-int x;
-for (x=0; x<40; ++x)
- t = t + a[x] + x;
-return t;
-}
-
-We generate:
-LBB1_1: #cond_true
- movl %ecx, %esi
- movl (%edx,%eax,4), %edi
- movl %esi, %ecx
- addl %edi, %ecx
- addl %eax, %ecx
- incl %eax
- cmpl $40, %eax
- jne LBB1_1 #cond_true
-
-GCC generates:
-
-L2:
- addl (%ecx,%edx,4), %eax
- addl %edx, %eax
- addl $1, %edx
- cmpl $40, %edx
- jne L2
+int %foo(int* %a, int %t) {
+entry:
+ br label %cond_true
+
+cond_true: ; preds = %cond_true, %entry
+ %x.0.0 = phi int [ 0, %entry ], [ %tmp9, %cond_true ] ; <int> [#uses=3]
+ %t_addr.0.0 = phi int [ %t, %entry ], [ %tmp7, %cond_true ] ; <int> [#uses=1]
+ %tmp2 = getelementptr int* %a, int %x.0.0 ; <int*> [#uses=1]
+ %tmp3 = load int* %tmp2 ; <int> [#uses=1]
+ %tmp5 = add int %t_addr.0.0, %x.0.0 ; <int> [#uses=1]
+ %tmp7 = add int %tmp5, %tmp3 ; <int> [#uses=2]
+ %tmp9 = add int %x.0.0, 1 ; <int> [#uses=2]
+ %tmp = setgt int %tmp9, 39 ; <bool> [#uses=1]
+ br bool %tmp, label %bb12, label %cond_true
+
+bb12: ; preds = %cond_true
+ ret int %tmp7
+}
-Smells like a register coallescing/reassociation issue.
+is pessimized by -loop-reduce and -indvars
//===---------------------------------------------------------------------===//
More information about the llvm-commits
mailing list