Re: throw(), pure and const flags on functions

[Jan Hubicka <hubicka at ucw dot cz>]

> I'm very much interested in data before this go in.
> There are claims out there that 'throw()' makes code much bigger.

Hmm, there is only scenario where throw() marker can make code bigger I
can think of:  until now, GCC was able to deduce throw() marker itself
in C++ FE and then when producing RTL code.  C++ FE is not doing
particularly good job because there is no dead/unreachable code removal
prior it and it should not need to care anyway.  This means
that all the dead EH did stay in intermediate representation until the
rest-of-compilation passes was called.  In partiuclar inliner sees code
with all the EH and code size estimates thus overestimate size of
functions that contains dead cleanups causing it to inline less.

On tramp3d there was over 10000 functions considered possibly throwing
during early optimization, and about 3000 functions considered after RTL
codegen. pure-const pass reorg got it down to about 300, ipa nothrow
discovery cut another half, couple extra got eliminated by the patch
making va_start notrhow, so we are left with over 100 functions.

Side effect of throw on inliner is mostly gone now since nothrow is
deduced during early passes and later at IPA level.  So if there are
remining cases where nothrow increase code size, fell free to assign PR
to me.   There should be mostly cases where early optimization missed
some transformation that became possible only during final optimization
pass.

> I'm also puzzled that the compile cannot deduce that a function
> that only only a function with 'throw()' is itself
> conceptually 'throw()' therefore does not need annotation.

We discussed this few mails before: compiler can't analyze function body
it does not see.  We are speaking about functions called from libstdc++
headers (i.e. from programs using libstdc++) and implemented in
libstdc++ shared library.  No matter how smart GCC gets, as long as
libstdc++ is shared, compiler won't be able to see the bodies and these
are in fact part of libstdc++ API.

So I agree that we should not blindly throw flags everywhere across
libstdc++ headers, but in the cases compiler can't deduce for good
reasons, we ought to.
> 
> I guess my point is that we should aim at keeping annotations
> minimum and teaching the compiler more about some
> composition things.

Well, I went pretty far teaching compiler about propagating stuff across
code it sees and noticed these problems because I was specifically
looking where all the analysis breaks.

Honza