introduce --param max-vartrack-expr-depth

[Jakub Jelinek]

On Tue, May 31, 2011 at 01:13:31PM -0300, Alexandre Oliva wrote:
> On May 30, 2011, Bernd Schmidt <bernds@codesourcery.com> wrote:
> 
> > On 05/30/2011 12:35 PM, Alexandre Oliva wrote:
> >> One of my patches for PR 48866 regressed guality/asm-1.c on
> >> x86_64-linux-gnu because what used to be a single complex debug value
> >> expression became a chain of debug temps holding simpler expressions,
> >> and this chain exceeded the default recursion depth in resolving
> >> location expressions.
> 
> > What's the worst that can happen if you remove the limit altogether?
> 
> Exponential behavior comes to mind.  I will try a bootstrap with a very
> high value, but for pathological cases we'd probably still need the
> param anyway, so I'll check it in.  Thanks for the reviews.

Yeah, before introduction of cselib_dummy_expand_value_rtx_cb
it used to be far more urgent, because with high depth values we'd create
tons of garbage even when it wouldn't lead to anything reasonable, but still
with very high depth values we could end up eating too much memory
and compiler time.  That said, perhaps default of say 20 instead of 10 wouldn't
be bad...
I'm not sure you want to bump the depth in reversible_op, because there it
blindly creates new rtx and folds them (on the other side, it doesn't have
a callback there, so it really doesn't matter how long chain of
DEBUG_EXPR_DECLs is).  I think 5 should be enough to get through LO_SUM
etc., perhaps it could be bumped a tiny bit but not too much.

	Jakub