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

Chris Lattner lattner at cs.uiuc.edu
Tue Apr 18 10:52:47 PDT 2006



Changes in directory llvm/lib/Target/PowerPC:

README_ALTIVEC.txt updated: 1.28 -> 1.29
---
Log message:

move some stuff around, clean things up


---
Diffs of the changes:  (+11 -14)

 README_ALTIVEC.txt |   25 +++++++++++--------------
 1 files changed, 11 insertions(+), 14 deletions(-)


Index: llvm/lib/Target/PowerPC/README_ALTIVEC.txt
diff -u llvm/lib/Target/PowerPC/README_ALTIVEC.txt:1.28 llvm/lib/Target/PowerPC/README_ALTIVEC.txt:1.29
--- llvm/lib/Target/PowerPC/README_ALTIVEC.txt:1.28	Mon Apr 17 22:57:35 2006
+++ llvm/lib/Target/PowerPC/README_ALTIVEC.txt	Tue Apr 18 12:52:36 2006
@@ -39,16 +39,12 @@
 
 //===----------------------------------------------------------------------===//
 
-FABS/FNEG can be codegen'd with the appropriate and/xor of -0.0.
-
-//===----------------------------------------------------------------------===//
-
 For functions that use altivec AND have calls, we are VRSAVE'ing all call
 clobbered regs.
 
 //===----------------------------------------------------------------------===//
 
-Implement passing vectors by value.
+Implement passing vectors by value into calls and receiving them as arguments.
 
 //===----------------------------------------------------------------------===//
 
@@ -57,13 +53,6 @@
 
 //===----------------------------------------------------------------------===//
 
-We currently codegen SCALAR_TO_VECTOR as a store of the scalar to a 16-byte
-aligned stack slot, followed by a load/vperm.  We should probably just store it
-to a scalar stack slot, then use lvsl/vperm to load it.  If the value is already
-in memory, this is a huge win.
-
-//===----------------------------------------------------------------------===//
-
 Do not generate the MFCR/RLWINM sequence for predicate compares when the
 predicate compare is used immediately by a branch.  Just branch on the right
 cond code on CR6.
@@ -75,6 +64,13 @@
 
 //===----------------------------------------------------------------------===//
 
+We currently codegen SCALAR_TO_VECTOR as a store of the scalar to a 16-byte
+aligned stack slot, followed by a load/vperm.  We should probably just store it
+to a scalar stack slot, then use lvsl/vperm to load it.  If the value is already
+in memory this is a big win.
+
+//===----------------------------------------------------------------------===//
+
 extract_vector_elt of an arbitrary constant vector can be done with the 
 following instructions:
 
@@ -87,8 +83,9 @@
 
 If we want to tie instruction selection into the scheduler, we can do some
 constant formation with different instructions.  For example, we can generate
-"vsplti -1" with "vcmpequw R,R" and 1,1,1,1 with "vsubcuw R,R", both of which
-use different execution units, thus could help scheduling.
+"vsplti -1" with "vcmpequw R,R" and 1,1,1,1 with "vsubcuw R,R", and 0,0,0,0 with
+"vsplti 0" or "vxor", each of which use different execution units, thus could
+help scheduling.
 
 This is probably only reasonable for a post-pass scheduler.
 






More information about the llvm-commits mailing list