https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102814
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
CC| |amacleod at redhat dot com
Ever confirmed|0 |1
Last reconfirmed| |2021-10-19
Status|UNCONFIRMED |NEW
--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> (In reply to Aldy Hernandez from comment #1)
> > Question to the larger audience... do we support bug reports against
> > internal --param constructs?
>
> Yes. Generally 'max-jump-thread-duplication-stmts' would suggest this is
> a parameter limiting code size growth and one that might affect compile-time
> in a linear fashion - exponential growth here is unexpected. The reporter
> states a 180 -> 181 parameter change trips this over unexpectedly which is
> a case worth investigating (it suggests a limit elsewhere is missing).
>
> For example the alias walking code counts the amount of "work" it does and
> has a limit on that, allowing linear growth parametrization. Not sure if
> there's sth in the threader and/or ranger that would support accumulating
> a work budget and stop after it is exhausted, but something like that would
> be very useful (not sure if that's the problem at hand in this case).
ISTR Andrew had some patches to stop solving for some combination of extremely
large PHIs. Not sure whether this is the issue at hand, but perhaps it's worth
looking at.
I'll put this in the back burner for now, since the loop threading restrictions
make this a non-issue, but I'll come back to it later.
Thanks.
