]> git.ipfire.org Git - thirdparty/gcc.git/commit
Cleanup expected_loop_iterations
authorJan Hubicka <jh@suse.cz>
Fri, 21 Jul 2023 06:52:00 +0000 (08:52 +0200)
committerJan Hubicka <jh@suse.cz>
Fri, 21 Jul 2023 06:52:54 +0000 (08:52 +0200)
commit89619f87697a0e0b54be4627f0f811f6c486ffe5
tree719a3aa6b98c081446ac7c071e2435a8726b9f5b
parentf32518726ee8e836d12d49aec8432679fcc42503
Cleanup expected_loop_iterations

this patch cleanups API for determining expected loop iteraitons from profile.
We started with having expected_loop_iterations and only source was the integer
represented BB counts. It did some work on guessing number of iteration if
profile was absent or bogus.  Later we introduced loop_info and added
get_estimated_loop_iterations which made expected_loop_iterations useful mostly
when doing profile updates and not for loop optimization heuristics.  The
naming is bit ambiguous so this difference is not clear.  Even later we
introduced precision tracking to profile and exended the API to return
reliablity of result but did not update all uses to do reasonable stuff with
it.  There is also some cofusion about +-1s concering latch execution counts
versus header execution counts.

This patch aims to obsolette expected_loop_iterations and
expected_loop_iterations_unbounded (and "suceeds" modulo 1 use of each of two).
It adds expected_loop_iterations_by_profile which computes sreal and does
correct precision/presence tracking.

Unlike old code, it is based on CFG profile only and  does not attempt to
provide fake answer when info is missing and does not check sanity with
loop_info.

We now define iterations consistently as lath execution in loop_info so I use
that here too.

I converted almost all calls to new API: dumps, code produing loop_info from
CFG profile and profile updating.  Remaining uses are in loop unrolling and
prefetching that needs more TLC I will do incrementally.

There are some improvements possible which I can play with incrementally.
 - for simple loops with one exit dominating latch we can use exit
   probability for easier to preserve info in loop itraionts.
   THis is probably not too critical since all esitmates should be recorded
   in loop_info and would help mostly if new loop is constructed or old
   loop is lost and redicovered.
 - We may want to avoid trusting the profile if it is obviously inconsistent
   on header.

gcc/ChangeLog:

* cfgloop.cc: Include sreal.h.
(flow_loop_dump): Dump sreal iteration exsitmate.
(get_estimated_loop_iterations): Update.
* cfgloop.h (expected_loop_iterations_by_profile): Declare.
* cfgloopanal.cc (expected_loop_iterations_by_profile): New function.
(expected_loop_iterations_unbounded): Use new API.
* cfgloopmanip.cc (scale_loop_profile): Use
expected_loop_iterations_by_profile
* predict.cc (pass_profile::execute): Likewise.
* profile.cc (branch_prob): Likewise.
* tree-ssa-loop-niter.cc: Include sreal.h.
(estimate_numbers_of_iterations): Likewise
gcc/cfgloop.cc
gcc/cfgloop.h
gcc/cfgloopanal.cc
gcc/cfgloopmanip.cc
gcc/predict.cc
gcc/profile.cc
gcc/tree-ssa-loop-niter.cc