Re: [PATCH] proper dataflow block visitation order

[Kenneth Zadeck <zadeck@naturalbridge.com>]

Seongbae Park (???, ???) wrote:
> This is an embarrassing mistake on my part that I only noticed this week,
> where we were using wrong block visit orders for dataflow analysis
> i.e. for forward problem, reverse postorder is the best known
> but we have been using postorder of inverted graph,
> and for backward problem, we should have used reverse postorder of
> inverted graph
> but we've been using postorder (of non-inverted).
>
> Two mistakes (of not reversing the postorder, and using wrong graph direction)
> canceled each other somewhat which made this mistake not noticeable
> for this long.
> The following patch reduces the total number of block visits during
> dataflow by about 4%
> building cc1 on i686, and it also reduces the block visits for the
> testcases in PR34400.
>
> While this is an overall win, there are cases where this patch increases
> the number of visits - I'll have to look at them further later,
> but clearly this is the right thing to do for now.
>
> Bootstrapped on i686 with c/c++ and no regression.
> While this is not exactly a regression,
> I'd like to commit this to 4.3 -
> as it's a fairly safe change (famous last word :).
> On the other hand, this is only a compile time fix
> and not a high-impact one at that,
> so I don't have very strong opinion on this.
>
> Seongbae
>
>
> 2008-02-08  Seongbae Park <seongbae.park@gmail.com>
>
>         * df-core.c (reverse_array, df_compute_postoder): New functions.
>         (rest_of_handle_df_initialize): Refactored
>         to call df_compute_postorder.
>         (df_analyze): Refactored to call df_compute_postorder.
>         Pass proper ordering for forward and backward problems.
>         (df_get_postorder): Return the correct block ordering.
>         (df_compact_blocks): Call df_compute_postorder.
>   
Does this effect the issues that were raised in pr34400?

this is clearly ok for 4.4. At this point mark mitchel has to approve it
for 4.3 and i assume the answer is no.

kenny