Re: [3.3] PR opt/12082

[Mark Mitchell <mark at codesourcery dot com>]

On Sat, 2003-09-06 at 12:09, Jan Hubicka wrote:
> > On Sat, 2003-09-06 at 00:47, Jan Hubicka wrote:
> > > Hi,
> > > the attached patch avoids the warning in this particular case, but it
> > > seems to me that there are quite a bit of other oppurtunities for such a
> > > problem to show up.  I hope that tree-ssa branch will have better answer
> > > for implementing such a warning.
> > 
> > This is again an instance of a general design bug: trying to use
> > optimization passes to generate warnings.  
> > 
> > Some day, we will just move all this stuff into front ends where it
> > belongs; putting it in the optimizers means that it will always be
> > broken, and the set of warnings will always change from release to
> > release.
> I would really love to see this done in the frontends, but on the other
> hand I don't think we want frontends to do some kind of CFG and dead
> code analysis just for such a warning.

No, we don't want the front ends to build a CFG.

We don't need them to be that smart.

These warnings are universally implemented in compilers in a pretty dumb
way.  That's fine; that's what users expect.  The warnings catch the
common cases:

  if (0) 
    foo(); // Unreachable

which are the ones people really want to get warned about.

This case:

  x = y + 1;
  if (f (x, y)) 
    foo ();

where "f" is some function that happens to return 0 if y is x + 1, for
all x and y, if you inline the heck out of everything and do a bunch of
range propagation to deduce the answer, is *not* something ordinary
users want to be warned about.  Part of the reason they don't want to be
warned about that is that a small change to "f", or its callees, will
change the answer.  So, it might be wrong for them to remove the code;
maybe when someone fixes a bug in "f", the call to "foo" will be
reachable again.

I have high confidence in these things because I've asked a lot of users
what they want from warnings over the years; I worked on a product whose
job was merely to generate useful warnings. 

> Moving things to tree-SSA makes it a bit cleaner but far from good
> sollution, so I don't see much a good answer for the problem.  Any idea
> what other compilers do?

Yes, they do what I said above -- they do naive tests in their front
ends.  For example, for unreachability, the test is usually something
like "has constant-folding made the test for this conditional zero?".

Even writing:

  void f() {
    int i = 0; 
    if (i) g(); 
  }

will not get you an unreachable code warning with most compilers, but
some are clever enough to get this case right; they notice that "i" is
never addressed/modified in the function and then implicitly make it
const, and then propagate all const variables into their conditions.

None of them try to build a CFG, or do real range propagation.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com