Add llvm::sys::getHostCPUName, for detecting the LLVM name for the host CPU.
[oota-llvm.git] / lib / Target / X86 / README-X86-64.txt
index bdff56d40bf809d2501e933b95a526e5ce6affc9..e8f7c5d6dd223e494f65aec7c48b82ea1e13c071 100644 (file)
@@ -5,14 +5,6 @@ PIC code model.
 
 //===---------------------------------------------------------------------===//
 
-Make use of "Red Zone".
-
-//===---------------------------------------------------------------------===//
-
-Implement __int128 and long double support.
-
-//===---------------------------------------------------------------------===//
-
 For this:
 
 extern void xx(void);
@@ -236,28 +228,73 @@ on the result of the movb).
 
 //===---------------------------------------------------------------------===//
 
-This function:
-double a(double b) {return (unsigned)b;} 
-compiles to this code:
-
-_a:
-       subq    $8, %rsp
-       cvttsd2siq      %xmm0, %rax
-       movl    $4294967295, %ecx
-       andq    %rcx, %rax
-       cvtsi2sdq       %rax, %xmm0
-       addq    $8, %rsp
-       ret
+The x86-64 ABI for hidden-argument struct returns requires that the
+incoming value of %rdi be copied into %rax by the callee upon return.
 
-note the dead rsp adjustments.  Also, there is surely a better/shorter way 
-to clear the top 32-bits of a 64-bit register than movl+andq.  Testcase here:
+The idea is that it saves callers from having to remember this value,
+which would often require a callee-saved register. Callees usually
+need to keep this value live for most of their body anyway, so it
+doesn't add a significant burden on them.
 
-unsigned long long c(unsigned long long a) {return a&4294967295; }
+We currently implement this in codegen, however this is suboptimal
+because it means that it would be quite awkward to implement the
+optimization for callers.
+
+A better implementation would be to relax the LLVM IR rules for sret
+arguments to allow a function with an sret argument to have a non-void
+return type, and to have the front-end to set up the sret argument value
+as the return value of the function. The front-end could more easily
+emit uses of the returned struct value to be in terms of the function's
+lowered return value, and it would free non-C frontends from a
+complication only required by a C-based ABI.
+
+//===---------------------------------------------------------------------===//
+
+We get a redundant zero extension for code like this:
+
+int mask[1000];
+int foo(unsigned x) {
+ if (x < 10)
+   x = x * 45;
+ else
+   x = x * 78;
+ return mask[x];
+}
 
-_c:
-       movl    $4294967295, %ecx
-       movq    %rdi, %rax
-       andq    %rcx, %rax
+_foo:
+LBB1_0:        ## entry
+       cmpl    $9, %edi
+       jbe     LBB1_3  ## bb
+LBB1_1:        ## bb1
+       imull   $78, %edi, %eax
+LBB1_2:        ## bb2
+       movl    %eax, %eax                    <----
+       movq    _mask@GOTPCREL(%rip), %rcx
+       movl    (%rcx,%rax,4), %eax
        ret
+LBB1_3:        ## bb
+       imull   $45, %edi, %eax
+       jmp     LBB1_2  ## bb2
+  
+Before regalloc, we have:
+
+        %reg1025<def> = IMUL32rri8 %reg1024, 45, %EFLAGS<imp-def>
+        JMP mbb<bb2,0x203afb0>
+    Successors according to CFG: 0x203afb0 (#3)
+
+bb1: 0x203af60, LLVM BB @0x1e02310, ID#2:
+    Predecessors according to CFG: 0x203aec0 (#0)
+        %reg1026<def> = IMUL32rri8 %reg1024, 78, %EFLAGS<imp-def>
+    Successors according to CFG: 0x203afb0 (#3)
+
+bb2: 0x203afb0, LLVM BB @0x1e02340, ID#3:
+    Predecessors according to CFG: 0x203af10 (#1) 0x203af60 (#2)
+        %reg1027<def> = PHI %reg1025, mbb<bb,0x203af10>,
+                            %reg1026, mbb<bb1,0x203af60>
+        %reg1029<def> = MOVZX64rr32 %reg1027
+
+so we'd have to know that IMUL32rri8 leaves the high word zero extended and to
+be able to recognize the zero extend.  This could also presumably be implemented
+if we have whole-function selectiondags.
 
 //===---------------------------------------------------------------------===//