https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219
Tamar Christina <tnfchris at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
--- Comment #9 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
This was a bit annoying to track down...
So BB 68 gets merged into BB 51,
BB 51 is loading 4 ints 8 - 12 out of 14.
So after it there's still 2 ints left to process. However it looks like the
compiler thinks that there can't be any more elements left.
It turns:
next_mask_416 = .WHILE_ULT (12, bnd.38_326, { 0, 0, 0, 0 });
if (next_mask_416 != { 0, 0, 0, 0 })
goto <bb 51>; [75.00%]
else
goto <bb 56>; [25.00%]
into
next_mask_373 = .WHILE_ULT (12, bnd.38_326, { 0, 0, 0, 0 });
goto <bb 56>; [100.00%]
where bb 56 is the lastb reduction bit. So basically we're 2 scalar loop
iterations short.
This seems to indicate like Richi suggested that nb_iterations_upper_bound is
set wrong.
Perhaps it was confused with the profitability threshold which went from 14 to
12.
Mine.
