An issue for the SC: horrible documentation quality of GCC

Richard Kenner kenner@vlsi1.ultra.nyu.edu
Fri May 9 22:51:00 GMT 2003


    For each use of the register (reg c) you look for the chain of
    operations preceeding it like:
    (set (reg b) (reg a)
    (set (reg c) (reg b)
    and you replace the use by the oldest copy of the value (reg a) in this
    case.

Why?  That seems, at best, to accomplish nothing and, at worst, to
pessimize the code.  I'm not familiar with the new register allocator,
but in the original one, all of those registers, assuming they are local,
will be tied together and all allocated the same hard register.

It would seem to me that when you do this optimization, you run the
real risk of increasing the lifetime of a register over what it was
before, especially if you consider the cases where some of the
registers in question are hard regs and some are global.  Don't we already
have code that knows how to handle these cases efficiently?

    I see, you are looking for something like (set (reg a) (reg b)) where
    reg b is known to be 100.  Constant propagation will turn this into
    (set (reg a) (reg 100)) but it is possible that copy propagation would
    eeliminate the need for reg a entirely replacing all the uses by reg b
    (or this can be done in register allocation).

I'm talking about register allocation, not copy propagation.

    In the compiler books this does not matter; 

A *lot* of things "don't matter" in compiler books: that's why they are
*books*.  ;-)

    It is not perfect, as in the case user already wrote code initializing
    variable to 100 many times, we won't cache the copy of 100 in a
    register.

But if the constant of 100 can fit into one insn, why would you *want to*
cache it in a register?  It's more efficient to use it each time rather
than waste a register.

    This is also interesting.  How well does the heuristic work?  In fact
    I would expect that it will often fail to elliminate the else block
    and result in moving NOP to the less frequently executed place in the
    superblock.

I'm not sure what you mean here.



More information about the Gcc mailing list