On 11/30/20 5:58 PM, Martin Sebor wrote:
>
> What I meant was that the recursion in compute_objsize has been
> there in various forms since at least GCC 8 (it's still in other
> parts of GCC today), and it hasn't been a source of reported
> problems.
Understood. Could be due to a variety of factors. Having the clamps is
still useful.
>
> I also never did understand how following a use-def chain of
> SSA_NAMEs could have any but linear complexity. For everything
> except PHIs the traversal is strictly linear; for PHIs, setting
> and testing the visited bitmap breaks cycles, again guaranteeing
> linear complexity. For reference, here are the numbers I put
> together last year (this was for get_range_strlen_dynamic, not
> compute_objsize):
> https://gcc.gnu.org/pipermail/gcc-patches/2019-July/525000.html
The worst of these cases tend to be when each block has thousands of
PHIs, each of which have thousands of arguments. This kind of scenario
happens with computed gotos, setjmp/longjmp, EH and similar
mechansisms. We've gone to great lengths to try and factor the gotos,
landing pads, etc to keep the complexity of the CFG (and indirectly the
complexity of the PHIs) to a minimum. Bugzilla is riddled with all
kinds of these issues. If you were to start wandering through them
you'd see the name Brad Lucier show up often ;-) His codes were often
the motivating case for various clamps.
So the walk up the use-def chains isn't usually too bad, though in
extreme cases, even the linear walk gets expensive.
>
> Anyway, whether it's actually needed or not, the limit's there
> now (in compute_objsize), and the caching should only make
> reaching it that much less likely.
>
Thanks.
jeff
