add a note
[oota-llvm.git] / lib / Target / README.txt
index 0096b0f9f42f100dd3950b625ac5599732fb66cc..d477c82fbb260421b368b4d1952b13c7ae4a59e7 100644 (file)
@@ -631,6 +631,25 @@ implementations of ceil/floor/rint.
 
 //===---------------------------------------------------------------------===//
 
+This GCC bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34043
+contains a testcase that compiles down to:
+
+       %struct.XMM128 = type { <4 x float> }
+..
+       %src = alloca %struct.XMM128
+..
+       %tmp6263 = bitcast %struct.XMM128* %src to <2 x i64>*
+       %tmp65 = getelementptr %struct.XMM128* %src, i32 0, i32 0
+       store <2 x i64> %tmp5899, <2 x i64>* %tmp6263, align 16
+       %tmp66 = load <4 x float>* %tmp65, align 16             
+       %tmp71 = add <4 x float> %tmp66, %tmp66         
+
+If the mid-level optimizer turned the bitcast of pointer + store of tmp5899
+into a bitcast of the vector value and a store to the pointer, then the 
+store->load could be easily removed.
+
+//===---------------------------------------------------------------------===//
+
 Consider:
 
 int test() {
@@ -672,3 +691,40 @@ instead of:
        ...
 
 //===---------------------------------------------------------------------===//
+
+http://llvm.org/PR717:
+
+The following code should compile into "ret int undef". Instead, LLVM
+produces "ret int 0":
+
+int f() {
+  int x = 4;
+  int y;
+  if (x == 3) y = 0;
+  return y;
+}
+
+//===---------------------------------------------------------------------===//
+
+The loop unroller should partially unroll loops (instead of peeling them)
+when code growth isn't too bad and when an unroll count allows simplification
+of some code within the loop.  One trivial example is:
+
+#include <stdio.h>
+int main() {
+    int nRet = 17;
+    int nLoop;
+    for ( nLoop = 0; nLoop < 1000; nLoop++ ) {
+        if ( nLoop & 1 )
+            nRet += 2;
+        else
+            nRet -= 1;
+    }
+    return nRet;
+}
+
+Unrolling by 2 would eliminate the '&1' in both copies, leading to a net
+reduction in code size.  The resultant code would then also be suitable for
+exit value computation.
+
+//===---------------------------------------------------------------------===//