https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amacleod at redhat dot com,
| |law at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Tamar Christina from comment #3)
> Aldy, any thoughts here?
We need a "real" threading expert on this one, as the decision by ranger is
correct. It looks like this is a profitability issue in the threader.
The problem can be seen with -O2 --param=threader-debug=all, on the threadfull1
dump:
The threaded path is:
path: 4->5->7 SUCCESS
ranger can fold the conditional in BB5:
if (_1 < 1.0e+0)
goto <bb 7>; [41.00%]
else
goto <bb 6>; [59.00%]
...because on entry to BB5 we know _1 < 0.0:
<bb 3> [local count: 955630225]:
_1 = (float) l_9;
_2 = _1 < 0.0;
zone1_15 = (int) _2;
if (_1 < 0.0)
goto <bb 4>; [41.00%]
else
goto <bb 5>; [59.00%]
<bb 4> [local count: 391808389]:
<bb 5> [local count: 955630225]:
# iftmp.0_10 = PHI <zone1_15(4), 1(3)>
fasten_main_natpro_chrg_init.2_3 = fasten_main_natpro_chrg_init;
_4 = fasten_main_natpro_chrg_init.2_3 * iftmp.0_10;
_5 = (float) _4;
if (_1 < 1.0e+0)
goto <bb 7>; [41.00%]
else
goto <bb 6>; [59.00%]
If this shouldn't be threaded because of a hot/cold issue, perhaps the code
goes in back_threader_profitability::profitable_path_p() where there's already
logic wrt hot blocks.
