Michael Meissner wrote:
>
> | I would start by reading the gcc source and studying the existing
> | back ends for x86 and a register rich one like Alpha. Next year
> | you might want to try changing a few things...
>
> That won't help much, since the register allocation logic is all in mostly
> machine independent code (there are various macros that control this, but the
> logic is more in MI code). What kills on the x86, is not just the scarcity of
> registers, but the fact that most of them have special uses. It is the special
> use that really kills register allocation, due to some design decisions in the
> register allocation.
If we lock 1Kb of L1 cache lines, and use these adresses just as if they
were a uniform set of 256 32-bit registers, do you think this would
improve the performance of the code generated by gcc?
The compiler would just see them as R1-R256 and would have a homogeneous
instruction set relative to these R1-R256 (a very large subset of the
standard X86 instruction set).
These pseudo-register instructions would have the same CPU clock cycle
count as standard register instructions.
Regards,
------------------------
André Balsa
andrebalsa@altern.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu