This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]