[llvm-commits] CVS: llvm/lib/Target/PowerPC/README_ALTIVEC.txt README.txt

[Chris Lattner]

Changes in directory llvm/lib/Target/PowerPC:

README_ALTIVEC.txt added (r1.1)
README.txt updated: 1.82 -> 1.83
---
Log message:

Split out altivec notes into their own README



---
Diffs of the changes:  (+56 -52)

 README.txt         |   54 +----------------------------------------------------
 README_ALTIVEC.txt |   54 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 56 insertions(+), 52 deletions(-)


Index: llvm/lib/Target/PowerPC/README_ALTIVEC.txt
diff -c /dev/null llvm/lib/Target/PowerPC/README_ALTIVEC.txt:1.1
*** /dev/null	Mon Mar 27 01:04:27 2006
--- llvm/lib/Target/PowerPC/README_ALTIVEC.txt	Mon Mar 27 01:04:16 2006
***************
*** 0 ****
--- 1,54 ----
+ //===- README_ALTIVEC.txt - Notes for improving Altivec code gen ----------===//
+ 
+ Implement TargetConstantVec, and set up PPC to custom lower ConstantVec into
+ TargetConstantVec's if it's one of the many forms that are algorithmically
+ computable using the spiffy altivec instructions.
+ 
+ //===----------------------------------------------------------------------===//
+ 
+ Implement PPCInstrInfo::isLoadFromStackSlot/isStoreToStackSlot for vector
+ registers, to generate better spill code.
+ 
+ //===----------------------------------------------------------------------===//
+ 
+ Altivec support.  The first should be a single lvx from the constant pool, the
+ second should be a xor/stvx:
+ 
+ void foo(void) {
+   int x[8] __attribute__((aligned(128))) = { 1, 1, 1, 1, 1, 1, 1, 1 };
+   bar (x);
+ }
+ 
+ #include <string.h>
+ void foo(void) {
+   int x[8] __attribute__((aligned(128)));
+   memset (x, 0, sizeof (x));
+   bar (x);
+ }
+ 
+ //===----------------------------------------------------------------------===//
+ 
+ Altivec: Codegen'ing MUL with vector FMADD should add -0.0, not 0.0:
+ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8763
+ 
+ We need to codegen -0.0 vector efficiently (no constant pool load).
+ 
+ When -ffast-math is on, we can use 0.0.
+ 
+ //===----------------------------------------------------------------------===//
+ 
+   Consider this:
+   v4f32 Vector;
+   v4f32 Vector2 = { Vector.X, Vector.X, Vector.X, Vector.X };
+ 
+ Since we know that "Vector" is 16-byte aligned and we know the element offset 
+ of ".X", we should change the load into a lve*x instruction, instead of doing
+ a load/store/lve*x sequence.
+ 
+ //===----------------------------------------------------------------------===//
+ 
+ There are a wide range of vector constants we can generate with combinations of
+ altivec instructions.  For example, GCC does: t=vsplti*, r = t+t.
+ 
+ //===----------------------------------------------------------------------===//
+ 


Index: llvm/lib/Target/PowerPC/README.txt
diff -u llvm/lib/Target/PowerPC/README.txt:1.82 llvm/lib/Target/PowerPC/README.txt:1.83
--- llvm/lib/Target/PowerPC/README.txt:1.82	Sat Mar 25 00:47:10 2006
+++ llvm/lib/Target/PowerPC/README.txt	Mon Mar 27 01:04:16 2006
@@ -1,3 +1,5 @@
+//===- README.txt - Notes for improving PowerPC-specific code gen ---------===//
+
 TODO:
 * gpr0 allocation
 * implement do-loop -> bdnz transform
@@ -309,12 +311,6 @@
 
 ===-------------------------------------------------------------------------===
 
-Implement TargetConstantVec, and set up PPC to custom lower ConstantVec into
-TargetConstantVec's if it's one of the many forms that are algorithmically
-computable using the spiffy altivec instructions.
-
-===-------------------------------------------------------------------------===
-
 Compile this:
 
 int foo(int a) {
@@ -502,11 +498,6 @@
 
 ===-------------------------------------------------------------------------===
 
-Implement PPCInstrInfo::isLoadFromStackSlot/isStoreToStackSlot for vector
-registers, to generate better spill code.
-
-===-------------------------------------------------------------------------===
-
 int foo(int N, int ***W, int **TK, int X) {
   int t, i;
   
@@ -524,32 +515,6 @@
 
 ===-------------------------------------------------------------------------===
 
-Altivec support.  The first should be a single lvx from the constant pool, the
-second should be a xor/stvx:
-
-void foo(void) {
-  int x[8] __attribute__((aligned(128))) = { 1, 1, 1, 1, 1, 1, 1, 1 };
-  bar (x);
-}
-
-#include <string.h>
-void foo(void) {
-  int x[8] __attribute__((aligned(128)));
-  memset (x, 0, sizeof (x));
-  bar (x);
-}
-
-===-------------------------------------------------------------------------===
-
-Altivec: Codegen'ing MUL with vector FMADD should add -0.0, not 0.0:
-http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8763
-
-We need to codegen -0.0 vector efficiently (no constant pool load).
-
-When -ffast-math is on, we can use 0.0.
-
-===-------------------------------------------------------------------------===
-
 float foo(float X) { return (int)(X); }
 
 Currently produces:
@@ -571,16 +536,6 @@
 
 ===-------------------------------------------------------------------------===
 
-  Consider this:
-  v4f32 Vector;
-  v4f32 Vector2 = { Vector.X, Vector.X, Vector.X, Vector.X };
-
-Since we know that "Vector" is 16-byte aligned and we know the element offset 
-of ".X", we should change the load into a lve*x instruction, instead of doing
-a load/store/lve*x sequence.
-
-===-------------------------------------------------------------------------===
-
 We generate ugly code for this:
 
 void func(unsigned int *ret, float dx, float dy, float dz, float dw) {
@@ -596,8 +551,3 @@
 
 ===-------------------------------------------------------------------------===
 
-There are a wide range of vector constants we can generate with combinations of
-altivec instructions.  For example, GCC does: t=vsplti*, r = t+t.
-
-===-------------------------------------------------------------------------===
-