Fix for df problems, and and an ifcvt improvement

Paolo Bonzini bonzini@gnu.org
Sat Apr 24 18:05:00 GMT 2010


> Looking at that patch, I can't make sense of your comment for
> df_simulate_initialize_forwards.  Clearly the artificial defs at the
> top must be set, not cleared, in the set of live regs?

In either case it won't be correct.  It will lack regs that are defined
at the top, but whose definitions do not generate liveness (i.e. they
are unused).

In general you're right that passes prefer to have an 
*over*approximation of liveness, that is show some dead registers as 
alive.  However, fwprop instead prefers an underapproximation, since a 
register erroneously marked as dead could simply prevent propagation 
into some REG_EQUAL or REQ_EQUIV notes.  That's why I left the fat 
comment that sort-of explained the situation.

Solutions include:

1) the attached partial reversal of r128957 (untested).  Then you'd just 
start iteration from DF_LR_TOP instead of DF_LR_IN.

2) making two more def/use bitmaps in df_lr_bb_local_compute that are 
the difference between top and out.  (i.e. copy use and def just before 
processing artificial refs at the top of the basic block).  Then make 
df_simulate_initialize_forwards compute TOP from OUT and these two. 
This would be more efficient

3) any of the two above, but controlled by a flag.

My favorite would be 2.  I don't think it would be necessary to control 
it by a flag, since the cost would be two bitmap copies per basic block 
per pass.  Unlike 1, it would not cost anything while solving the DF 
problem.

> The patch below seems to fix a lot of failures on i686-linux with my
> peephole2 patch also applied.

What is this patch?

> Maybe we don't even need to do anything at all if the DF_LIVE_IN
> bitmap is correct?

DF_LIVE_IN is "above" the artificial defs, while 
df_simulate_initialize_forwards initializes it to below the artificial defs.

Paolo
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gg.patch
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20100424/33bd4b59/attachment.ksh>


More information about the Gcc-patches mailing list