[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