https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109893
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
This is a failure to jump-thread because of size limits. If we'd limit
the backward threader the same way as the forward threader we'd optimize this
(--param fsm-scale-path-stmts=1).
--param max-jump-thread-duplication-stmts is 15
--param fsm-scale-path-stmts is 2
but for "true" FSM paths we allow --param max-fsm-thread-path-insns == 100
For non-loop FSM threads we only allow 7 stmts (and we lack the forward
thread estimation of the number of stmts we likely eliminate).
Increasing --param max-jump-thread-duplication-stmts to 17 also works to
resolve the regression.
But IMHO the scale param should simply go - we have the other limit for
paths across a backedge when threading multi-way branches. The argument
for the scaling is
/* The generic copier used by the backthreader does not re-use an
existing threading path to reduce code duplication. So for that
case, drastically reduce the number of statements we are allowed
to copy. */
that sounds more like limiting overall threading rather than individual
ones. I'll adjust fsm-scale-path-stmts to be more finely tunable.
