Hans-Peter Nilsson wrote:
I think the necessity and urgency of IRA_COVER_CLASSES, calls
for a few more details to be documented.
tm.texi says for it:
Cover classes are a set of non-intersecting register
classes covering all hard registers used for register allocation
purposes.
Ok, so I can construct a set from reg_class already. It's so
simple a gen* program could do it. But I hear, some tweaking is
usually at least recommended.
Actually I tried to construct an algorithm to build IRA_COVER_CLASSES
but I failed. There are usually several variants of choosing
IRA_COVER_CLASS. Some of them will work best (with performance point of
view). Some (or all in worst case scenario) variants might result in
reload bugs and some pattern and reload related macros tweaking will be
need.
Should I prune that set and if so, what's a good huristic to
prune it? Which classes *must* I keep? The ones used with
REG_CLASS_FROM_CONSTRAINT/REG_CLASS_FROM_LETTER? Should
e.g. singleton classes be avoided for some reason?
My experience shows that classes in IRA_COVER_CLASS should be as big as
possible. So it is better to avoid singleton classes. But again there
might be exceptions (as I remember ppc has one signleton class separated
from GENERAL_REGS).
I tried to implement algorithm to choose IRA_COVER_CLASSES as biggest
non-intersected classes within each cover class any hard-register moving
(if it is possible) is cheaper than load or store of the register.
It also says:
Any move between two registers in the same cover class
should be cheaper than load or store of the registers.
But, one of the classes, is such that I can't move between
registers *within* the same class (just between that class and
GENERAL_REGS or memory)! How should I treat that class? Or
maybe the documentation should be amended to say "If a move
between two registers in the same cover class are possible, it
should be cheaper than a load or store"? (Looking at the ARM
port, it looks like the answer to the last question is "yes".)
Yes, that is true. Your definition is more clear and unambigous. I'll
post a patch with your variant.
