Re: [tree-ssa] New regressions as of 2003-11-04

[law at redhat dot com]

In message <1068000647.7039.211.camel@p4>, Andrew MacLeod writes:
 >SSA->normal doesnt klnow
 >anything about equivilences, and Im not too keen on teaching it anything
 >about them.
I kind-of guessed that :-)


 >I dont understand why the existing routines wont work with a little
 >tweaking... The inforamtion is still identical, there just happens to be
 >a branch in between instead of the stmt hung off the COND_EXPR.  If the
 >existing stuff does destroy the CFG, perhaps we ought to do this part of
 >it before we destroy the CFG.....
FWIW, I just looked over the useless statement remover and as I expected
I'm 99.9% sure it's not safe to try and use the CFG inside that code.

For example, if you have a block which looks like

 block X
 (void)0
 (void)0
 stmt1
 stmt2
 (void)0
 

It looks like this at the IL level

     CE0
     /\
    /  \
   /    \
(void)0  \
         CE1
         /\
        /  \
       /    \
  (void)0    \
              CE2
              /\
             /  \
            /    \
          stmt1   \
                  CE3
                   /\
                  /  \
                 /    \
                /      \
              stmt2   (void)0


The basic block head tree pointer will point to either CE0 or the first
(void)0 (I can never remember which).  The basic block tail tree pointer
will point to the final (void )0.

After the useless statement remover that entire tree will be collapsed into

     CE2
     /\
    /  \
   /    \
 stmt1  stmt2

And the tree head/tail pointers are _not_ updated.  While they could be
kept up to date, it would probably add a fair amount of complexity to
this code.


So the difficulty in performing these optimizations in the new scheme
of lowered COND_EXPRs mostly boils down to the inability to easily and
reliably find the destination of the GOTO_EXPRs.  Remember, 
GOTO_DESTINATION will point to a LABEL_DECL, not the LABEL_EXPR.

You might think you could do this during the first traversal of the
statements in the useless statement remover, but that assumes that
the COND_EXPR always shows up before any PHI nodes it controls, which
I do not think is a safe assumption.

We'd basically have to write a new optimizer which sat between out-of-ssa
and the current useless statement remover to detect the cases we care
about.

jeff