Re: some tree-ssa vs mainline stats

[law at redhat dot com]

In message <200306192238.h5JMcN4X002760@gremlin.ics.uci.edu>, Dan Nicolaescu wr
ites:
 >--=-=-=
 >
 >law@redhat.com writes:
 >
 >  >  >
 >  >  >Also there's a lot of "if (1)" and "if (0)" code.
 >  > I'd love to have a compilable example.  If we've got if (1) or if (0) cod
 >e
 >  > lying around, I'd definitely want to have a deeper look.
 >
 >Sure, compile the attached code with the c++ compiler. 
 >It's from PR8361, I have no idea what the code does.
 >
 >There are a lot of class and template definitions, that have a lot of
 >inline functions, but just 2 functions defined at the top level:
 >"sameComponentInHead" and "MODEL_GENERATOR::initialiseRules".
 >The .optimized dump for the first one has a few if (1)s and the second
 >has some if (0)s.
Thanks.    It's an interesting little problem, and mostly an issue of the
cleanup code not knowing how to remove the BIND_EXPRs associated with
the untaken arms of conditionals.



Here's a simplified example:

class DEPGRAPH
    {
public:
    unsigned getAtomComponent(bool assert=true) const
        {
        if( assert )
            {
                extern void foo(void);
                foo();
            }
        else
            {
                extern void bar (void);
                bar ();
            }
        }
    };
bool sameComponentInHead(const DEPGRAPH &g)
    {
    g.getAtomComponent();
    }


The renaming into SSA optimizations correctly detect that value of
"assert" in the IF statement will be 1 and do the proper replacement.

CCP notices that ELSE is unreachable code and removes all the executable
statements in the ELSE arm.


Now the 3 things I see here are:


  1. It may be profitable to have the SSA renamer go ahead and do CFG
  cleanups.  The reason being if we remove an edge, we probably get to
  remove PHI alternatives, or maybe remove PHI nodes completely.  Which
  reduces the amount of work for the renamer.

  2. Once we've removed the executable statements in the ELSE arm in CCP,
  we're left with a BIND_EXPR which contains a FUNCTION_DECL in its variable
  list.  As a result, we don't recognize the tree as empty.  Thus we don't
  remove the ELSE arm and linearize this control structure.

  3. Even once we leave SSA form, the useless statement remover is unable
  to zap the unnecessary BIND_EXPR (and linearize the IF) because of the
  FUNCTION_DECL on the BIND_EXPR's variable list.


I'll put this on my TODO list.

Thanks,
Jeff