Re: introduce --param max-vartrack-expr-depth

[Jakub Jelinek <jakub@redhat.com>]

On Wed, Jul 20, 2011 at 01:07:40PM -0700, Michael Eager wrote:
> I've run into a problem with this change when building microblaze-xilinx-elf.
> 
> When compiling _divdi3.o, cselib_expand_value_rtx_1 returns a huge rtx
> tree for variable _r1 when max_depth is greater than 17.  If -g is
> specified, this later results in attempting to generate a DWARF location
> list much larger than the 0xffff size limit, resulting in an assert failure.

I think Alex is working on a patch which will hopefully improve it.
In 4.6-RH in the mean time we are defaulting max-vartrack-expr-depth to 12
instead, perhaps that would be better than 10.

As for the 0xffff size limit, I'd say we should handle it instead of
asserting, e.g. if the size is 64K or more, we could emit there a single
DW_OP_call4 + DW_TAG_dwarf_procedure that would contain it.
Or just drop the range on the floor, still better than ICE.

> 2011-07-20  Michael Eager  <eager@eagercon.com>
> 
>         * params.def (PARAM_MAX_VARTRACK_EXPR_DEPTH): Default to 10.
> 
> Index: gcc/params.def
> ===================================================================
> --- gcc/params.def      (revision 176533)
> +++ gcc/params.def      (working copy)
> @@ -845,7 +845,7 @@
>  DEFPARAM (PARAM_MAX_VARTRACK_EXPR_DEPTH,
>           "max-vartrack-expr-depth",
>           "Max. recursion depth for expanding var tracking expressions",
> -         20, 0, 0)
> +         10, 0, 0)

	Jakub