Mark vector ctpop, cttz, and ctlz as Expand on x86.
[oota-llvm.git] / lib / Target / README.txt
index e55513b395acfa5ed511646ee94849ee6a450f60..2db7e64874b99de6f6f671c0812fe1d94b673577 100644 (file)
@@ -1,21 +1,20 @@
 Target Independent Opportunities:
 
-===-------------------------------------------------------------------------===
+//===---------------------------------------------------------------------===//
 
-FreeBench/mason contains code like this:
+With the recent changes to make the implicit def/use set explicit in
+machineinstrs, we should change the target descriptions for 'call' instructions
+so that the .td files don't list all the call-clobbered registers as implicit
+defs.  Instead, these should be added by the code generator (e.g. on the dag).
 
-static p_type m0u(p_type p) {
-  int m[]={0, 8, 1, 2, 16, 5, 13, 7, 14, 9, 3, 4, 11, 12, 15, 10, 17, 6};
-  p_type pu;
-  pu.a = m[p.a];
-  pu.b = m[p.b];
-  pu.c = m[p.c];
-  return pu;
-}
+This has a number of uses:
 
-We currently compile this into a memcpy from a static array into 'm', then
-a bunch of loads from m.  It would be better to avoid the memcpy and just do
-loads from the static array.
+1. PPC32/64 and X86 32/64 can avoid having multiple copies of call instructions
+   for their different impdef sets.
+2. Targets with multiple calling convs (e.g. x86) which have different clobber
+   sets don't need copies of call instructions.
+3. 'Interprocedural register allocation' can be done to reduce the clobber sets
+   of calls.
 
 //===---------------------------------------------------------------------===//
 
@@ -63,17 +62,6 @@ which will be removed once the proper fix is made.
 
 //===---------------------------------------------------------------------===//
 
-Turn this into a signed shift right in instcombine:
-
-int f(unsigned x) {
-  return x >> 31 ? -1 : 0;
-}
-
-http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25600
-http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01492.html
-
-//===---------------------------------------------------------------------===//
-
 On targets with expensive 64-bit multiply, we could LSR this:
 
 for (i = ...; ++i) {
@@ -105,6 +93,8 @@ int foo(int z, int n) {
   return bar(z, n) + bar(2*z, 2*n);
 }
 
+Reassociate should handle the example in GCC PR16157.
+
 //===---------------------------------------------------------------------===//
 
 These two functions should generate the same code on big-endian systems:
@@ -117,20 +107,6 @@ for 1,2,4,8 bytes.
 
 //===---------------------------------------------------------------------===//
 
-This code:
-int rot(unsigned char b) { int a = ((b>>1) ^ (b<<7)) & 0xff; return a; }
-
-Can be improved in two ways:
-
-1. The instcombiner should eliminate the type conversions.
-2. The X86 backend should turn this into a rotate by one bit.
-
-//===---------------------------------------------------------------------===//
-
-Add LSR exit value substitution. It'll probably be a win for Ackermann, etc.
-
-//===---------------------------------------------------------------------===//
-
 It would be nice to revert this patch:
 http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060213/031986.html
 
@@ -140,9 +116,9 @@ stuff too.
 
 //===---------------------------------------------------------------------===//
 
-For packed types, TargetData.cpp::getTypeInfo() returns alignment that is equal
+For vector types, TargetData.cpp::getTypeInfo() returns alignment that is equal
 to the type size. It works but can be overly conservative as the alignment of
-specific packed types are target dependent.
+specific vector types are target dependent.
 
 //===---------------------------------------------------------------------===//
 
@@ -155,7 +131,7 @@ v4sf example(float *P) {
 
 //===---------------------------------------------------------------------===//
 
-We should constant fold packed type casts at the LLVM level, regardless of the
+We should constant fold vector type casts at the LLVM level, regardless of the
 cast.  Currently we cannot fold some casts because we don't have TargetData
 information in the constant folder, so we don't know the endianness of the 
 target!
@@ -194,23 +170,42 @@ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17687
 
 Scalar Repl cannot currently promote this testcase to 'ret long cst':
 
-        %struct.X = type { int, int }
+        %struct.X = type { i32, i32 }
         %struct.Y = type { %struct.X }
-ulong %bar() {
-        %retval = alloca %struct.Y, align 8             ; <%struct.Y*> [#uses=3]
-        %tmp12 = getelementptr %struct.Y* %retval, int 0, uint 0, uint 0
-        store int 0, int* %tmp12
-        %tmp15 = getelementptr %struct.Y* %retval, int 0, uint 0, uint 1
-        store int 1, int* %tmp15
-        %retval = cast %struct.Y* %retval to ulong*
-        %retval = load ulong* %retval           ; <ulong> [#uses=1]
-        ret ulong %retval
+
+define i64 @bar() {
+        %retval = alloca %struct.Y, align 8
+        %tmp12 = getelementptr %struct.Y* %retval, i32 0, i32 0, i32 0
+        store i32 0, i32* %tmp12
+        %tmp15 = getelementptr %struct.Y* %retval, i32 0, i32 0, i32 1
+        store i32 1, i32* %tmp15
+        %retval.upgrd.1 = bitcast %struct.Y* %retval to i64*
+        %retval.upgrd.2 = load i64* %retval.upgrd.1
+        ret i64 %retval.upgrd.2
 }
 
 it should be extended to do so.
 
 //===---------------------------------------------------------------------===//
 
+-scalarrepl should promote this to be a vector scalar.
+
+        %struct..0anon = type { <4 x float> }
+
+define void @test1(<4 x float> %V, float* %P) {
+        %u = alloca %struct..0anon, align 16
+        %tmp = getelementptr %struct..0anon* %u, i32 0, i32 0
+        store <4 x float> %V, <4 x float>* %tmp
+        %tmp1 = bitcast %struct..0anon* %u to [4 x float]*
+        %tmp.upgrd.1 = getelementptr [4 x float]* %tmp1, i32 0, i32 1
+        %tmp.upgrd.2 = load float* %tmp.upgrd.1
+        %tmp3 = mul float %tmp.upgrd.2, 2.000000e+00
+        store float %tmp3, float* %P
+        ret void
+}
+
+//===---------------------------------------------------------------------===//
+
 Turn this into a single byte store with no load (the other 3 bytes are
 unmodified):
 
@@ -275,3 +270,198 @@ It would also be nice to recognize the reg->size doesn't alias reg->node[i], but
 alas...
 
 //===---------------------------------------------------------------------===//
+
+This isn't recognized as bswap by instcombine:
+
+unsigned int swap_32(unsigned int v) {
+  v = ((v & 0x00ff00ffU) << 8)  | ((v & 0xff00ff00U) >> 8);
+  v = ((v & 0x0000ffffU) << 16) | ((v & 0xffff0000U) >> 16);
+  return v;
+}
+
+Nor is this (yes, it really is bswap):
+
+unsigned long reverse(unsigned v) {
+    unsigned t;
+    t = v ^ ((v << 16) | (v >> 16));
+    t &= ~0xff0000;
+    v = (v << 24) | (v >> 8);
+    return v ^ (t >> 8);
+}
+
+//===---------------------------------------------------------------------===//
+
+These should turn into single 16-bit (unaligned?) loads on little/big endian
+processors.
+
+unsigned short read_16_le(const unsigned char *adr) {
+  return adr[0] | (adr[1] << 8);
+}
+unsigned short read_16_be(const unsigned char *adr) {
+  return (adr[0] << 8) | adr[1];
+}
+
+//===---------------------------------------------------------------------===//
+
+-instcombine should handle this transform:
+   icmp pred (sdiv X / C1 ), C2
+when X, C1, and C2 are unsigned.  Similarly for udiv and signed operands. 
+
+Currently InstCombine avoids this transform but will do it when the signs of
+the operands and the sign of the divide match. See the FIXME in 
+InstructionCombining.cpp in the visitSetCondInst method after the switch case 
+for Instruction::UDiv (around line 4447) for more details.
+
+The SingleSource/Benchmarks/Shootout-C++/hash and hash2 tests have examples of
+this construct. 
+
+//===---------------------------------------------------------------------===//
+
+Instcombine misses several of these cases (see the testcase in the patch):
+http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01519.html
+
+//===---------------------------------------------------------------------===//
+
+viterbi speeds up *significantly* if the various "history" related copy loops
+are turned into memcpy calls at the source level.  We need a "loops to memcpy"
+pass.
+
+//===---------------------------------------------------------------------===//
+
+Consider:
+
+typedef unsigned U32;
+typedef unsigned long long U64;
+int test (U32 *inst, U64 *regs) {
+    U64 effective_addr2;
+    U32 temp = *inst;
+    int r1 = (temp >> 20) & 0xf;
+    int b2 = (temp >> 16) & 0xf;
+    effective_addr2 = temp & 0xfff;
+    if (b2) effective_addr2 += regs[b2];
+    b2 = (temp >> 12) & 0xf;
+    if (b2) effective_addr2 += regs[b2];
+    effective_addr2 &= regs[4];
+     if ((effective_addr2 & 3) == 0)
+        return 1;
+    return 0;
+}
+
+Note that only the low 2 bits of effective_addr2 are used.  On 32-bit systems,
+we don't eliminate the computation of the top half of effective_addr2 because
+we don't have whole-function selection dags.  On x86, this means we use one
+extra register for the function when effective_addr2 is declared as U64 than
+when it is declared U32.
+
+//===---------------------------------------------------------------------===//
+
+Promote for i32 bswap can use i64 bswap + shr.  Useful on targets with 64-bit
+regs and bswap, like itanium.
+
+//===---------------------------------------------------------------------===//
+
+LSR should know what GPR types a target has.  This code:
+
+volatile short X, Y; // globals
+
+void foo(int N) {
+  int i;
+  for (i = 0; i < N; i++) { X = i; Y = i*4; }
+}
+
+produces two identical IV's (after promotion) on PPC/ARM:
+
+LBB1_1: @bb.preheader
+        mov r3, #0
+        mov r2, r3
+        mov r1, r3
+LBB1_2: @bb
+        ldr r12, LCPI1_0
+        ldr r12, [r12]
+        strh r2, [r12]
+        ldr r12, LCPI1_1
+        ldr r12, [r12]
+        strh r3, [r12]
+        add r1, r1, #1    <- [0,+,1]
+        add r3, r3, #4
+        add r2, r2, #1    <- [0,+,1]
+        cmp r1, r0
+        bne LBB1_2      @bb
+
+
+//===---------------------------------------------------------------------===//
+
+Tail call elim should be more aggressive, checking to see if the call is
+followed by an uncond branch to an exit block.
+
+; This testcase is due to tail-duplication not wanting to copy the return
+; instruction into the terminating blocks because there was other code
+; optimized out of the function after the taildup happened.
+;RUN: llvm-upgrade < %s | llvm-as | opt -tailcallelim | llvm-dis | not grep call
+
+int %t4(int %a) {
+entry:
+        %tmp.1 = and int %a, 1
+        %tmp.2 = cast int %tmp.1 to bool
+        br bool %tmp.2, label %then.0, label %else.0
+
+then.0:
+        %tmp.5 = add int %a, -1
+        %tmp.3 = call int %t4( int %tmp.5 )
+        br label %return
+
+else.0:
+        %tmp.7 = setne int %a, 0
+        br bool %tmp.7, label %then.1, label %return
+
+then.1:
+        %tmp.11 = add int %a, -2
+        %tmp.9 = call int %t4( int %tmp.11 )
+        br label %return
+
+return:
+        %result.0 = phi int [ 0, %else.0 ], [ %tmp.3, %then.0 ],
+                            [ %tmp.9, %then.1 ]
+        ret int %result.0
+}
+
+//===---------------------------------------------------------------------===//
+
+Tail recursion elimination is not transforming this function, because it is
+returning n, which fails the isDynamicConstant check in the accumulator 
+recursion checks.
+
+long long fib(const long long n) {
+  switch(n) {
+    case 0:
+    case 1:
+      return n;
+    default:
+      return fib(n-1) + fib(n-2);
+  }
+}
+
+//===---------------------------------------------------------------------===//
+
+Argument promotion should promote arguments for recursive functions, like 
+this:
+
+; RUN: llvm-upgrade < %s | llvm-as | opt -argpromotion | llvm-dis | grep x.val
+
+implementation   ; Functions:
+
+internal int %foo(int* %x) {
+entry:
+        %tmp = load int* %x
+        %tmp.foo = call int %foo(int *%x)
+        ret int %tmp.foo
+}
+
+int %bar(int* %x) {
+entry:
+        %tmp3 = call int %foo( int* %x)                ; <int>[#uses=1]
+        ret int %tmp3
+}
+
+
+