Re: [tree-ssa] Statement with no effect warning

[Jan Hubicka <hubicka at ucw dot cz>]

> In message <jmfzfkwpu8.fsf@desire.geoffk.org>, Geoff Keating writes:
>  >Jan Hubicka <jh@suse.cz> writes:
>  >
>  >> > In message <20031216160527.GN2199@kam.mff.cuni.cz>, Jan Hubicka writes:
>  >> >  >Ignore the comments about non-checking bootstrap.  As I've checked
>  >> >  >Diego's machines did run earlier than I've commited the patch.  Hope
>  >> >  >that all the problems are fixed by now.
>  >> > What I'm far more concerned about is the fact that a patch which didn't
>  >> > bootstrap was checked into the tree to start with.
>  >> 
>  >> I see you don't believe, it, but it really did bootstrap.  As I pointed
>  >> out already, it only reproduce on disabled checking bootstrap, while I
>  >> did bootstrap with checking enabled (the default settings).
>  >
>  >Can we fix this?  It would be better if it was impossible to write
>  >code that will build on a compiler with checking enabled but won't
>  >build on a compiler with checking disabled.
> What I've typically found with this kind of problem is that with
> checking disabled the resulting source code is simplified enough that
> suddenly new optimization opportunities are exposed and thus code within
> the optimizers is exercised more heavily than before.
> 
> Now, one of my goals as I've been working on the SSA optimizers is to get
> them to a point where this happens less often by making the optimizers better
> at optimizing away useless checking code.
> 
> Clearly  we can't make all the checking code go away, but the better the
> optimizers are at determining that a particular hunk of checking code is
> redundant the more likely we are to not have situations where a checking
> bootstrap succeeds and a no-checking bootstrap fails.

This touch the fundamental problem on whether we want stupid warnings
done by front-end or ultra smart warnings done by optimizers.  It seems
to me that we are somewhat shizofrenic in this area moving both
directions at once. 

Argument for first is that users at least can understandt he stupidity
and warnings get more predictable (for instance tree-SSA is getting
smarter about uninitialized variable warning and we have to fix new and
new cases all the time and the warnings are inlining sensitive that
depends on a lot of factors), while the other of course is that smarter
warnings would not have obvious false positives and can warn about
interesting situations.

I would preffer the first, just because it makes things easier and more
regular tought.  It seems to me that the warnings shall be moved to the
frontend or at latest to pass just after gimplification, so
optimizations have no effect on what warnings are emit and what not.

Honza
> 
> jeff
> 
> 
>