This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: Quickly discard pseudo lifeness information after reload
Bernd Schmidt wrote:
Better to do this right after reload?
Do you mean after this code in global.c:rest_of_handle_global_alloc ?
/* If optimizing, allocate remaining pseudo-regs. Do the reload
pass fixing up any insns that are invalid. */
if (optimize)
failure = global_alloc (dump_file);
else
{
build_insn_chain (get_insns ());
failure = reload (get_insns (), 0);
}
Maybe it's because it's past 3am, but I can't actually determine
whether this is the only problem with our life information. I'm
pretty sure reload inheritance can make hard regs live across jumps,
Do you mean in extended basic blocks, i.e. over the fall-through edge of
a condjump?
and reload doesn't create new death notes for its regs. Where is all
that supposed to be updated?
The postreload passes have a notion of what is and what isn't reliable
in the available live info (although I wouldn't vouch for that to be
correct and still up-to-date after all the changes made to the compiler
in the recent years). They also do some insn churning of their own.
flow2 does a gobal update, which is supposed to clear up all this mess,
but first it does insn splitting, which in turn calls
find_many_sub_basic_blocks. I've seen that almost double the number of
basic blocks, and duplicating all the stale pseudo live information for
the new blocks seems rather wasteful.
If we free up the pseudo live information at the start of flow2, we'll
also be able to reuse the freed bitmap elements when we allocate the
bitmaps for the new basic blocks.
Hmm, that makes me wonder: if we know that we've just put lots of stuff
into the free litst, and are about to allocate from it, does it pay to
sort the free list by address, in order to improve locality of reference
later?