This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] Increase max depth in vt_expand_*loc


Hi!

http://bugzilla.redhat.com/616050
shows that the the maximum depth is not deep enough for common cases.
I've already needed to bump this limit in a patch for a DWARF extension I'm
working on, when hitting it now even without that patch I think we should
just increase the limit.

Now that we don't really create RTL first, but only check whether it will be
possible to do so, even with deeper depth we'll actually allocate further
something only if it leads to a usable location description.

Bootstrapped/regtested on x86_64-linux and i686-linux.  Ok for trunk?

2010-07-20  Jakub Jelinek  <jakub@redhat.com>

	* var-tracking.c (vt_expand_loc, vt_expand_loc_dummy): Bump maximum
	depth to 8 from 5.

--- gcc/var-tracking.c.jj	2010-06-30 08:22:00.000000000 +0200
+++ gcc/var-tracking.c	2010-07-20 10:26:23.000000000 +0200
@@ -7055,7 +7055,7 @@ vt_expand_loc (rtx loc, htab_t vars)
   data.vars = vars;
   data.dummy = false;
   data.cur_loc_changed = false;
-  loc = cselib_expand_value_rtx_cb (loc, scratch_regs, 5,
+  loc = cselib_expand_value_rtx_cb (loc, scratch_regs, 8,
 				    vt_expand_loc_callback, &data);
 
   if (loc && MEM_P (loc))
@@ -7076,7 +7076,7 @@ vt_expand_loc_dummy (rtx loc, htab_t var
   data.vars = vars;
   data.dummy = true;
   data.cur_loc_changed = false;
-  ret = cselib_dummy_expand_value_rtx_cb (loc, scratch_regs, 5,
+  ret = cselib_dummy_expand_value_rtx_cb (loc, scratch_regs, 8,
 					  vt_expand_loc_callback, &data);
   *pcur_loc_changed = data.cur_loc_changed;
   return ret;

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]