------- Comment #30 from zadeck at naturalbridge dot com  2007-08-29 15:34 
-------
Subject: Re:  [4.3 Regression] ecj1 hangs

bonzini at gnu dot org wrote:
> ------- Comment #29 from bonzini at gnu dot org  2007-08-29 14:16 -------
> (When I said "post your first patch", I meant the first one from comment #26;
> if my "fixing the mess" works, it'll not be necessary anymore).
>
>
>   
For some reason, I was not copied on any of the postings for this patch
until this morning.

First, thankyou Jakub and Andreas for going this.

I think that it is obvious that you have spotted the exact problem: in
some way shape form of fashion, the artificial uses at the end of the
block need to be re added into the live set after the processing of each
insn in the block.

There are two ways of doing this (assume that you have a local variable
called artificial_uses_fixup which is a pointer to either
df->eh_block_artificial_uses or
df->regular_block_artificial_uses depending on if the block has eh preds) :

1) you can explicitly or artificial_uses_fixup into local_live after
processing each insn.
2) you can test artificial_uses_fixup along with local_live when setting
needed.

As noted, (1) has the problem that may cause an infinite loop.  This
infinite loop could be fixed by changing the equation for block_changed
to be

!bitmap_equal (local_live, DF_LR_IN (BB) || artificial_uses_fixup)

i.e. the infinite loop is because DF_LR_IN may be deficient in some of
the bits in artificial_uses_fixup for basically the same reason that
caused the bug in the first place.

I personally think that solution (1) is preferable to (2) because it is
fewer bitmap operations even though it will require a extra temp bitmap
to hold the or.

But either patch is a reasonable approach. 

As far as why there are all of the df_simulate functions that do things
in different ways, the answer is that the code has evolved and sometimes
things get missed.

The addition of the df->eh_block_artificial_uses and
df->regular_block_artificial_uses sets is fairly recent and it would
most likely be useful to replace walks  of artificial_uses with them. 

Kenny


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32758

Reply via email to