Hi all,
I'm convinced that saturation and sufficiency based approaches are the
future of register pressure management.
[Please keep my colleague Sid Touati in CC of this thread, until he
registers to the list.]
Unfortunately, the state of the art (more recent that the thesis
referenced in the original email, see Touati's web page) is limited to
basic block and software-pipelining scopes, and limited to scheduling.
Compared to the tasks currently managed by reload, it certainly misses a
whole bunch of instruction selection and immediate operand/address mode
corner case problems (depending on the target). It also misses global
scheduling, but extended BB scheduling is not very hard to approximate,
as well as superblock scheduling.
I'm not at all a knowledgeable person to tell you what to do in the case
of GCC, but for sure saturation/sufficiency-based approches are not
sufficient to kill the dragon.
However, I will strongly advise anybody (= Kenny Zadeck) looking at a
fresh SSA-based backend design to consider such an approach to avoid
messing up with pressure-aware-* where * is any backend pass that bears
a risk of blowing up register pressure.
If you interested in collaboration on the topic, we are about to start
extending those approaches to general control-flow, and implementing it
in a production compiler (not GCC, but a free one, and not LLVM either).
Albert
Dave Korn wrote:
Michael Kruse wrote:
So, now my questions: How much do you think could this could improve
compiled code speed? Would the current GCC/YARA benefit from such an
optimization pass at all? What are the chances that this could get into
the main GCC tree if it shows up to be an improvement?
One of the major problems in gcc is the intertangling of instruction
selection with register allocation and spill generation. If these could be
separated it would almost certainly generate better code and be welcomed with
open arms!
I'd prefer to implement this for the gcc, but my advisor wants me to do
it for the university's own compiler. Therefore I could also need
arguments why to do it for the GCC.
Because destroying reload(*) would be an incalculable public service and
your name will be remembered in history as the one who slew the dragon? ;-)
cheers,
DaveK
