On Mar 1, 2007, at 12:57 AM, Tehila Meyzels wrote:
Revital Eres wrote on 01/03/2007 10:37:36:
Hello,
I wonder why this order (non-consecutive, decreasing) of Altivec
registers
was chosen when specifying the allocation order in REG_ALLOC_ORDER.
(taken from rs6000.h)
/* AltiVec registers. */ \
77, 78, \
90, 89, 88, 87, 86, 85, 84, 83, 82, 81, 80, \
79, \
96, 95, 94, 93, 92, 91, \
108, 107, 106, 105, 104, 103, 102, 101, 100, 99, 98, 97, \
109, 110, \
111, 112, 113 \
I think part of the answer can be found here:
http://gcc.gnu.org/ml/gcc/2003-06/msg00902.html
"We have found that re-arranging the REG_ALLOC_ORDER in rs6000.h so
that all
the FP registers come after the integer registers greatly reduces the
tendency of the compiler to generate code that moves 8-byte quantites
through the FP registers."
I don't think so, the ordering above is in the original Altivec patch
here
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00453.html
which precedes that discussion by over a year.
Obviously you want to use caller-saved registers before callee-saved
ones.
The consecutive reverse ordering of the callee-saved registers
matches the
ordering in the save/restore routines in the Altivec PIM (also found in
darwin-vecsave.asm), which is desirable for that mechanism to work well.
(The common ordering doesn't logically have to be reversed; I'd guess
that
was chosen to be analogous to the integer stmw/lmw instructions.)
The ordering of the caller-saved regs looks odd to me. V13..V2
should be used
in that order to minimize conflict with parameters and return
values. V0 and V1
are preferred to those, and I'd expect V14..V19 to be preferred also,
but they
aren't. Perhaps to minimize the code that sets up VRsave?
