[Bug tree-optimization/18133] computed gotos are not folded back to regular gotos when it is found that they are not computed gotos at all

[law at redhat dot com]

------- Additional Comments From law at redhat dot com  2005-01-24 20:46 -------
Subject: Re:  computed gotos are not folded
	back to regular gotos when it is found that they are not computed gotos at
	all

On Sun, 2005-01-23 at 21:09 +0000, kazu at cs dot umass dot edu wrote:
> ------- Additional Comments From kazu at cs dot umass dot edu  2005-01-23 21:09 -------
> Here is another idea that would not compilicate the DOM.
> That is, we can set up things so that the actual threading part will be
> done by DOM.
> 
> Suppose we have a factored computed goto block like so:
> 
>   # p_2 = PHI <&L0(0), &L1(1), p_3(2)>;
>   # b_1 = PHI <3(0), 5(1), 4(2)>;
> <L2>:;
>   ... possibly some other statements ...
>   goto p_2;
> 
> 
> Let's split this block like so:
> 
> 
>   # p_2 = PHI <&L0(0), &L1(1), p_3(2)>;
>   # b_1 = PHI <3(0), 5(1), 4(2)>;
> <L2>:;
>   ... possibly some other statements ...
> 
> <L3>:;      // fall through from L2.
>   goto p_2;
> 
> 
> Note that we are still in SSA form without need for rewriting.
> 
> Now let's add a new PHI node and a new SWITCH_EXPR to <L2> like so:
> 
> 
>   # p_2 = PHI <&L0(0), &L1(1), p_3(2)>;
>   # b_1 = PHI <3(0), 5(1), 4(2)>;
>   # fac_1 = PHI <0(0), 1(1), 2(2)>;
> <L2>:;
>   ... possibly some other statements ...
>   switch (fac_1)
>     {
>     case 0: goto L0;    <- a threadable, normal edge
>     case 1: goto L1;    <- a threadable, normal edge
>     default: goto <L3>; <- not threadable because p_3 is an SSA_NAME
>     }
> 
> <L3>:;
>   goto p_2;
> 
> That is, we create a new PHI node fac_1 so that we can build a
> dispatch table using a SWITCH_EXPR.
> 
> Now it's easy for DOM to pick up the jump threading opportunities at
> SWITCH_EXPR.
> 
> If you like, you can say that we "reduce" the factored computed goto
> block to a SWITCH_EXPR.
> 
> Any thoughts?
Interesting approach.   I'm not sure if your approach is easier
than just expanding the threading code to handle threading indirect
jumps.

I don't initially *think* that extending the threading code would be 
all that difficult.  In fact, all I think we need to do is update
the selection code to detect this case -- I think the code to update
the CFG and SSA graphs will DTRT without any changes.

Jeff



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18133