Questions about compute_transpout in gcse.c code hoisting implementation

[Jeff Law]

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