Re: COND_EXPR lowering patch

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

>  >as the code works now all statements here including the condition
>  >will be marked as useful.
> And we care because? 

because why would we want to have a code that does not anything at all?

> Yes, this kid of thing does happen, but not that often.

No, it will happen always -- you cannot create a condition in lowered
for that would not be marked useful.

> Plus we already 
> have code to handle it and collapse the IF away when both arms just jump to
> the same location.

yes, this is exactly why I don't consider the condition removal part in
the optimization critical.

> However, what I have failed to consider is that if we keep the COND_EXPR
> straightening code currently in tree_cleanup_cfg, and install your patch
> to flatten COND_EXPRs, then we may be able remove all the control dependency
> stuff in code in dce.c.
> 
> When I first attempted this on the assumption that if DCE killed all the
> statements in both arms of a COND_EPXR that we should easily be able to
> determine the COND_EXPR itself was uselss during cleanup_tree_cfg the
> typical cases we missed looked something like
> 
> 
> if (a)
>   {
>     {
>       {
>          (void)0
>       }
>     }
>   }
> else
>   {
>     {
>       {
>         (void)0
>       }
>     }
>   }
> 
> [ Possibly with multiple empty statements strung throughout the arms. ]
> 
> Ie, DCE deleted all the executable statements, but since I had turned off
> control statement removal, DCE left in the skeleton with the COND_EXPR.  
> And since the arms were trivial empty statements, linearize_cond_expr couldn't
> do anything with it.
> 
> 
> Now, if we keep linearize_cond_expr with your COND_EXPR lowering code we
> would see 
> 
> if (a)
>   {
>     (void)0
>   }
> else
>   {
>     (void)0
>   }

uh?  Then you probably have other idea about the shape "lowered
COND_EXPRs" should have.  In what I do, this would look like

if (a)
  goto x;
else
  goto y;

x:
  (void)0
goto z;

y:
 (void)0
z:

> Which linearize_cond_expr knows how to remove (and for which lazily build
> pdoms -- so the vast majority of the time we don't have to pay the cost of
> building pdoms.
>
> 
> So what we _may_ want is your COND_EXPR lowering code, removal of the
> control structure stuff in tree-ssa-dce.c and keep linearize_cond_expr.

well, in fact I don't like linearize_cond_expr very much.  Instead we
want jump threading (cfg cleanup version, i.e. over cfg cleanup only) +
a simplified version of linearize_cond_expr that will just cancel
conditions both of whose branches has the same target.

The above code first becomes

if (a)
  goto z;
else
  goto z;
...
z:,

then everything is removed.

Zdenek