This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] proper dataflow block visitation order
- From: Kenneth Zadeck <zadeck at naturalbridge dot com>
- To: "Seongbae Park (???, ???)" <seongbae dot park at gmail dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, "Bonzini, Paolo" <bonzini at gnu dot org>
- Date: Fri, 08 Feb 2008 20:26:08 -0500
- Subject: Re: [PATCH] proper dataflow block visitation order
- References: <ab3a61990802081707p22da0980rda3d184f66963267@mail.gmail.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