Move rest_of_handle_ branch)prob before GCSE

Move rest_of_handle_ branch)prob before GCSE

[Qiong Cai]

Hi,

Currently in toplev.c, the optimizations order is something like the
following:

...                             <= position A
[rest_of_handle_gcse]
[rest_of_handle_loop_optimize]
[rest_of_handle_jump_bypass]
[rest_of_handle_cfg]
[rest_of_handle_branch_prob]    <= position B
....

Now, if I move branch_prob to position A before gcse , does this change
affect the optimizations after branch_prob?
From the performance results, they are slight different.

The function "rest_of_handle_branch_prob" mainly contains two functions
"branch_prob" and "estimate_probability".
I think "branch_prob" has no effect for later optimizations (CFG is not
changed, only instrumenation/collection profiling), but
"estimate_probability" use the characteristic of CFG to determine the
probability, which may generate different probabilities at position A/B,
because the optimizations between A and B change the CFG. The
probabilities provided by "estimate_probability" are used by other later
optimizations such as "basic block reorder".

I'd like to know whether my explanation is correct or complete. Is there
any other reason  the performance results are slightly different?


Thanks.

Qiong

Re: Move rest_of_handle_ branch)prob before GCSE

[Jan Hubicka]

> Hi,
> 
> Currently in toplev.c, the optimizations order is something like the
> following:
> 
> ...                             <= position A
> [rest_of_handle_gcse]
> [rest_of_handle_loop_optimize]
> [rest_of_handle_jump_bypass]
> [rest_of_handle_cfg]
> [rest_of_handle_branch_prob]    <= position B
> ....
> 
> Now, if I move branch_prob to position A before gcse , does this change
> affect the optimizations after branch_prob?
> >From the performance results, they are slight different.
> 
> The function "rest_of_handle_branch_prob" mainly contains two functions
> "branch_prob" and "estimate_probability".
> I think "branch_prob" has no effect for later optimizations (CFG is not
> changed, only instrumenation/collection profiling), but
> "estimate_probability" use the characteristic of CFG to determine the
> probability, which may generate different probabilities at position A/B,
> because the optimizations between A and B change the CFG. The
> probabilities provided by "estimate_probability" are used by other later
> optimizations such as "basic block reorder".
> 
> I'd like to know whether my explanation is correct or complete. Is there
> any other reason  the performance results are slightly different?

The problem is that loop optimizer rebuilds the CFG so the branch
predictions are lost.  You can't move it across pass not preserving the
profile so until we replace loop optimizer by new one, we have to keep
it this way.

Honza
> 
> 
> Thanks.
> 
> Qiong

RE: Move rest_of_handle_ branch_prob before GCSE

[Qiong Cai]

Hi, 

As "rest_of_handle_branch_prob" mainly contains two functions, one is
"branch_prob" for collecting real profiling and instrumentation, and
"estimate_probability" for estimating profiling. I'd like to use "real"
profiling in "gcse" pass and later optimizations use "estimated"
profiling. Do you think the following configuration make sense:

[branch_prob]           
      // collecting real profiling or instrumentation for gcse module
[rest_of_handle_gcse]
flag_branch_probability = 0;
      // only consider "estimated" profiling in later optimizations
[rest_of_handle_loop_optimize}
[rest_of_handle_jump_bypass]
[rest_of_handle_cfg]
[estimate_probability]

Will this configuration have negative impact on other optimizations
apart from "gcse" pass?

Thanks.


Qiong







> Hi,
> 
> Currently in toplev.c, the optimizations order is something like the
> following:
> 
> ...                             <= position A
> [rest_of_handle_gcse]
> [rest_of_handle_loop_optimize]
> [rest_of_handle_jump_bypass]
> [rest_of_handle_cfg]
> [rest_of_handle_branch_prob]    <= position B
> ....
> 
> Now, if I move branch_prob to position A before gcse , does this 
> change affect the optimizations after branch_prob?
> >From the performance results, they are slight different.
> 
> The function "rest_of_handle_branch_prob" mainly contains two 
> functions "branch_prob" and "estimate_probability". I think 
> "branch_prob" has no effect for later optimizations (CFG is not 
> changed, only instrumenation/collection profiling), but 
> "estimate_probability" use the characteristic of CFG to determine the 
> probability, which may generate different probabilities at position 
> A/B, because the optimizations between A and B change the CFG. The 
> probabilities provided by "estimate_probability" are used by other 
> later optimizations such as "basic block reorder".
> 
> I'd like to know whether my explanation is correct or complete. Is 
> there any other reason  the performance results are slightly 
> different?

The problem is that loop optimizer rebuilds the CFG so the branch
predictions are lost.  You can't move it across pass not preserving the
profile so until we replace loop optimizer by new one, we have to keep
it this way.

Honza
> 
> 
> Thanks.
> 
> Qiong

Re: Move rest_of_handle_ branch_prob before GCSE

[Zdenek Dvorak]

Hello,

> As "rest_of_handle_branch_prob" mainly contains two functions, one is
> "branch_prob" for collecting real profiling and instrumentation, and
> "estimate_probability" for estimating profiling. I'd like to use "real"
> profiling in "gcse" pass and later optimizations use "estimated"
> profiling. Do you think the following configuration make sense:
> 
> [branch_prob]           
>       // collecting real profiling or instrumentation for gcse module
> [rest_of_handle_gcse]
> flag_branch_probability = 0;
>       // only consider "estimated" profiling in later optimizations
> [rest_of_handle_loop_optimize}
> [rest_of_handle_jump_bypass]
> [rest_of_handle_cfg]
> [estimate_probability]
> 
> Will this configuration have negative impact on other optimizations
> apart from "gcse" pass?

definitely.  You usually get much better results by using the real
profile than by estimating it.

We are currently working on getting rid of the old loop optimizer, which
would enable moving profiling before gcse (probably even much sooner,
really.) We hope to be able to do this in 3.5, although the situation of
the tree-ssa branch makes this quite unsure.

For now I however do not see a problem with the other approach -- using
the profile estimation in pre-loop passes.

Zdenek