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

[tom fogal <tfogal at alumni dot unh dot edu>]

Hi!  I've been watching this thread with interest.

Jan Hubicka <hubicka@ucw.cz> writes:
> > 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.

So marking functions as throw() is generally a Good Thing?  Or is this
going to be GCC specific?

I've read other literature that suggests explicit throw() is a Bad Thing:

  http://www.boost.org/development/requirements.html#Exception-specification

Quick quote:

  A "dumb" compiler, however, may make all kinds of pessimizations.

  For example, some compilers turn off inlining if there is an
  exception-specification. Some compilers add try/catch blocks. Such
  pessimizations can be a performance disaster which makes the code
  unusable in practical applications.

The above document does note that the logic is only good for inline
functions (which had somehow slipped my memory when I started this
email..).

The response I'll probably get is `benchmark on your compilers and
see', but I'm curious if it's even worth annotating my code && running
a benchmark.  Would you say a large reduction in code size is typical?
Or are the efforts really only justified for widely-used library code?

Thanks,

-tom

> > 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