This is the mail archive of the gcc@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: Questions about compute_transpout in gcse.c code hoisting implementation


On 01/26/10 16:47, Steven Bosscher wrote:
Hello Jeff and other interested readers :-)

There is a function compute_transpout() in gcse.c and there are a
couple of things about this functions that I don't understand exactly.


First, there is this comment before the function says:


"An expression is transparent to an edge unless it is killed by
the edge itself. This can only happen with abnormal control flow,
when the edge is traversed through a call. This happens with
non-local labels and exceptions. "

What does this mean, exactly? The implementation of the function
simply kills all expressions that are MEM_P if a basic block ends with
a CALL_INSN (with a wrong comment about something flow did in the gcc
dark ages, say 15 years ago). But I don't see how compute_transpout
handles non-local labels. And what about non-call exceptions?
I believe rth added this code along time ago to avoid ever needing to insert an insn on an abnormal edge during gcse. IIRC the hoisting code utilizes the same compute_transpout and thus inherits this behaviour.



Second, it looks like gcc says that an expression can be in VBEOUT, but can not be hoisted. In hoist_code this is expressed like so:

	  if (TEST_BIT (hoist_vbeout[bb->index], i)
	&&  TEST_BIT (transpout[bb->index], i))
	    {
	      /* We've found a potentially hoistable expression, now
		 we look at every block BB dominates to see if it
		 computes the expression.  */

Why does the code hoisting pass not do the same as the LCM-PRE pass:
Eliminate expressions it cannot handle early on? In this case,
wouldn't it be easier (better?) to eliminate expressions that are not
TRANSPOUT from VBEOUT in compute_vbeinout? Would it be OK if I teach
compute_vbeinout to eliminate expressions that may trap from VEBOUT,
if there are exception edges to successor blocks? This is similar to
what LCM-PRE does in compute_pre_data (well, more or less, sort-of,
etc.).
Hoisting was a quick transcription of Muchnick's algorithm and hasn't been touched too much since. I don't see that there's anything to lose by pruning the expression sets early.

jeff



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