Re: Gforth and gcc "progress"

Anton Ertl wrote:

Andrew Haley <andrew29@xxxxxxxxxxxxxxxxxxxxxxx> writes:
Bernd Paysan <bernd.paysan@xxxxxx> wrote:

There are a number of complications with this sort of split lifetime
register allocators, especially since debuggers have problems to
localize values when they change their position during the program
flow. One interim solution is to disable this sort of optimization
when debugging.

With the move to static single assignment form (aka SSA), gcc
effectively does this anyway.

I don't think so (even if the coalescing back does not happen).

I think the argument is different: The main roadblock for using a split
lifetime register allocator, when I last proposed one (must be 10 years
ago) was that gdb has problems with that. Now since GCC may have "walking"
variables, anyway (through the SSA optimizations), the roadblock of not
being able to debug this stuff is already gone. So it's possible to replace
GCC's current allocator with such an allocator without giving up debugging.

I don't know how important the coalescing is, because stack frame packing is
also better achieved by treating the stack frame as (hypothetically
infinitely large) register file. The algorithm should free "dead" slots
(like in a register file), and try to put new values into the slots with
the smallest offset (smallest, because that way the "hot" stuff gets in as
few cache lines as possible, and on variable length architectures like x86,
8 bit offsets give better code size). The same thing is also useful for
register files in some architectures which have a save-multiple-register
instruction (like ARM), where caller-saved registers should live in
consecutive registers.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
.

Relevant Pages

  • Re: Gforth and gcc "progress"
    ... One particular gripe I have with typical register allocators and the usage ... writing it to memory and later reloading it is perfectly ok. ... especially since debuggers have problems to localize ...
    (comp.lang.forth)
  • Re: Code density and performance?
    ... there are many simple ways to increase code density ... >> without seriously complicating implementation or impacting ... >> Coalescing register allocators can in most cases eliminate the ... That is, if set, the destination is the "next" register from the first ...
    (comp.arch)
  • Re: Code density and performance?
    ... >>> Coalescing register allocators can in most cases eliminate the ... allow only a small subset of the N^2 or N^3 possible pairs and triples ...
    (comp.arch)
  • Re: [RFC][GIT PULL][PATCH 0/10 -tip] cpu_debug patches 20090613
    ... developer who is porting/developing the kernel or drivers. ... Which is perfectly fine to do low level debugging. ... Support Temperature sensor for AMD 11H ... And what is triggering the printout of a particular register? ...
    (Linux-Kernel)
  • Re: Debugging issue to watch variable values
    ... is mismatch during debugging even if I supply the same PDB file generated for the exactly the same release binary code. ... The PDB file is created as the same time as the executable, ... If yes to 1, then during compile/link time, whether variable will be put on stack or in register is still not decided, only during runtime will the location be decided. ...
    (microsoft.public.vc.language)