Re: Speedup to propagate_one_insn

[law at redhat dot com]

In message <20040205163522.GT21096@kam.mff.cuni.cz>, Jan Hubicka writes:
 >Bootstrapped/regetsted i686-pc-gnu-linux, OK?
 >Honza
 >
 >2004-02-05  Jan Hubicka  <jh@suse.cz>
 >	* recog.c (split_all_insns): Do not update reg info.
 >	* regrename.c (regrename_optimize): Likewise.
 >	* toplev.c (rest_of_handle_reorder_blocks): Likewise.
 >	* flow.c (struct propagate_block_info): Add insn_num field.
 >	(reg_deaths): New array.
 >	(life_analysis): Free reg_deaths info.
 >	(allocate_reg_life_data): Allocate reg_deaths array.
 >	(propagate_one_insn): Use new array.
 >	(init_propagate_block): Initialize it.
 >	(free_propagate_block_info): Finish compuation of REG_LIVE_LENGTH
 >	(attempt_auto_inc): Sanity check that REG_INFO is not computed
 >	at same time.
 >	(mark_used_regs): Update new array.
Funny, I had noticed basically the same thing within the last couple
weeks as I was analyzing a register allocation issues with tree-ssa.
Since ultimately this issue doesn't affect how registers are allocated,
I just noted it and went on with my analysis.

 >Index: cp/tree.c
I suspect you didn't mean to include this hunk

 >+ /* When PROP_REG_INFO set, array containing information at what
 >+    instruction given register died.  */
 >+ static int *reg_deaths;
So what happens when a register dies more than once in a block?
Oh, I see where that's handled.  You might want to add a comment
either to reg_deaths or somewhere in the code which briefly describes
how pbi->num_insn - reg_deaths represents the number of insns
between the most recent death of the register and the current instruction
within the block.

Consider it pre-approved after removal of the cp/tree.c hunk and a
slight update to the comments for the issue noted above.

--

What I was pondering to fix this problem was to compute n_insns on a 
per-block basis.

For registers which are live through the block (ie, they never die in the
block) we'd use n_insns.  For registers which die in the block we'd 
fall back to something like what we do now.


Of course I haven't actually tried to implement it, so I don't know
how feasible my scheme is.


BTW, is the qty comparison function in local/global showing up at all? 
There's some obvious lossage in those as well, though it may not be
enough to matter.

jeff