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]

Re: vartracking speedup


On Thu, Jun 03, 2010 at 03:49:19AM +0200, Jan Hubicka wrote:
> while looking into oprofiles, I noticed that dataflow_set_equiv_regs shows
> quite top (0.6%) and pretty much all goes to memset.  It is because at the end
> of basic block for each pseudo we clear NUM_MACHINE_MODES words that
> is quite some memory.
> 
> This patch adds a check if (set->regs[i]) to prevent the heavy work when
> nothing is chnaged.

I'd instead just add
      if (set->regs[i] == NULL) 
	continue;
before the memset, as many lines in the loop are already very long and
indenting them further means going over the 80th column (and your patch
doesn't try to wrap them).
Otherwise it looks good, while it never showed up for me in callgrind
dumps very high, I expect that e.g. on ia64 with its 334 hard registers
and many modes it could be significant.

Furthermore, I believe it could be even
      /* If the list is empty or one entry, no need to canonicalize
	 anything.  */
      if (set->regs[i] == NULL || set->regs[i]->next == NULL)
	continue;
In ~ 80%-90% of cases set->regs[i] is NULL, while 2 and longer chains
are just in 0.01s of percents on the testcases I've tried.
When the list has just one entry, either it is not a value or has non-zero
offset, then canon isn't touched and none of the loops does anything, or
it is a value, then canon for its mode is set, but the second loop
will do
		if (val == cval)
		  continue;
and the third one shouldn't have VALUE_RECURSED_INTO set and so should
continue as well.  Will fire off a bootstrap to verify this assumption.

> Bootstrapped/regtested x86_64-linux, OK?
> 
> 	* var-trackin.c (dataflow_set_equiv_regs): Avoid hard work
> 	when pseudo is not changed.

s/trackin/tracking/ in the ChangeLog.  Also, set->regs[i] != NULL
doesn't mean a register has changed, it is a list of tracked values
in that register.  So the CL entry should say e.g. "Shortcut the loop if
set->regs[i] is NULL."

	Jakub


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