On Fri, Mar 18, 2011 at 06:45:57PM +0100, Paolo Bonzini wrote:
> > Is the live problem so much more useful for crossjumping than lr problem?
> > All it wants to prove is if it can safely move a couple of instructions
> > across some other instructions, and the live_union bitmap that is computed
> > using the live/lr problem is used to find out if registers set by the
> > moved instructions are actually live at the end of those instructions
> > or not. What would be an example where live problem would allow optimizing
> > more than lr?
>
> LIVE == LR except when you have uninitialized uses.
>
> Unless it is needed for correctness, I see no reason to prefer LIVE to
> LR at -O1.
So, looking at some rtl dumps with uninitialized vars at -O2, I see
that LR out is either the same as LIVE out, or contains some extra regs
(the uninitialized ones). But this all is at the end of a bb
which contains insns that set those registers (can_move_insns_across
is only interested in test_set registers from the merge_live bitmap).
Thus I believe it is fine both for corectness and even generated code
quality to just use LR (i.e. LIVE vs. LR should make no difference
on the crossjumping).
That said, I'm currently also bootstrapping/regtesting following patch
just in case:
2011-03-18 Jakub Jelinek <ja...@redhat.com>
PR rtl-optimization/48156
* combine-stack-adj.c (rest_of_handle_stack_adjustments): Compute live
problem if flag_crossjumping && optimize <= 1.
--- gcc/combine-stack-adj.c.jj 2010-12-02 11:51:32.000000000 +0100
+++ gcc/combine-stack-adj.c 2011-03-18 18:02:04.000000000 +0100
@@ -551,7 +551,16 @@ gate_handle_stack_adjustments (void)
static unsigned int
rest_of_handle_stack_adjustments (void)
{
- cleanup_cfg (flag_crossjumping ? CLEANUP_CROSSJUMP : 0);
+ if (flag_crossjumping && optimize <= 1)
+ {
+ df_live_add_problem ();
+ df_live_set_all_dirty ();
+ df_analyze ();
+ cleanup_cfg (CLEANUP_CROSSJUMP);
+ df_remove_problem (df_live);
+ }
+ else
+ cleanup_cfg (flag_crossjumping ? CLEANUP_CROSSJUMP : 0);
/* This is kind of a heuristic. We need to run combine_stack_adjustments
even for machines with possibly nonzero TARGET_RETURN_POPS_ARGS
Jakub
