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. _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
