This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

X86 and register classes



After lots of oprofile runs and some work taming rtx_cost() and other
functions that recursively walk RTL, two functions remain top of the
list on x86, one of which is record_reg_classes.

Clearly this is because x86 has _TWENTY FIVE_ register classes.  This
explodes the cost tables and the complexity of the alternative
scanning per-class loops record_reg_classes has to do.  It also
contributes to reload complexity, but I'll leave that for another
future investigation.

Let's look at what N_REG_CLASSES is for some other targets:

Sparc:			9
PA-32:			8
PA-64:			8
MIPS:			17
Alpha:			7
IA-64:			11
fr30:			7
d30v:			12
s390:			7
rs6000:			18
sh:			15
v850:			3

The only thing I can say for some of those larger cases, including
x86, is "Yikes!"

It's a shame we compute costs considering MMX, SSE, float regs, etc.
when we are looking at an add of two SI mode values for example.  Sure
in some weird case we can transform it into an MMX add or something
like that, but most of the time it is wasted work in regclass.

Next note, in trying to consider ways to improve this situation, is
the fact that record_reg_classes traverses two different cost tables
indexed like:

	MAX_MACHINE_MODE X N_REG_CLASSES X N_REG_CLASSES

Sometimes the 'class' loop index applies to the second index
and sometimes to the third.  That has to really stink for cache
usage, in fact it's probably close to perfectly suboptimal (each index
replaces the L1 cache line used by the previous interation).

Some day we'd like GCC to be able to optimize this such that the
tables will be walked more linearly in memory.  However, today such an
optimization does not exist in GCC so we have to do this by hand.  The
best way to go about this is to make the linear indexing occur with
the rightmost index.

I tried this with may_move_in_cost[] but this didn't seem to help
things much, if at all.  Ho hum...

An area of exploration for improvements for someone so inclined...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]