throw(), pure and const flags on functions

[Jan Hubicka]

> 
> That's clearly not an issue about underlying C library functions, though.
> 
> People care about the code generated at -O0, i.e., without inlining.  In
> particular, code size can matter -- if your program doesn't fit on your
> embedded target when unoptimized, that can be a problem.  Removing
> unused implicitly-generated exception regions does not affect
> debuggability; by construction, there's no way for a user to talk about
> them, set a breakpoint there, etc.
> 
> I don't know if the analysis Jan is doing works at -O0, or not.  If it
> doesn't, I'd like to know if it can, at least to some extent.  But,

Pure-const pass does not run at -O0, so nothrow markers are not issued.
>From compile time/size stats of C++ tester it was win in both metrics on
all C++ benchmarks we have, so if it seems useful, I can try to get it
anabled at -O0.  It would mean bit re-shuffling of early optimization
queue since we put it in the middle of early optimization passes, but it
is easilly doable.

> without optimization there are certainly going to be cases that the
> compiler won't figure out that it otherwise could.  Therefore, it may
> still be valuable to mark functions in the library as not throwing
> exceptions.
> 
> Users don't care about how hard it was to write the library.  They care
> only about how well it works.  Of course we should make the compiler as
> smart as we can; that saves work for users, including, but not limited
> to, the libstdc++ maintainers.  But, the libstdc++ maintainers should be
> willing to add annotations if necessary to make user programs smaller
> and/or faster, even if that is somewhat untidy, and even if the compiler
> could sometimes do better.
> 
> I can't tell if you're arguing against adding annotations or not.  I
> think we should add them to declarations of functions that cannot throw
> exceptions, if those functions call only other functions that do not
> throw exceptions, and if that improves the code generated at any level
> of optimization.  I think we should have compiler warnings to help with
> this: both a warning that a function could safely be declared as
> "throw()", and a warning that a function declared "throw()" calls
> functions that themselves appear capable of throwing exceptions.

I have first warning here; one problem why I didn't sent it yet is the
fact that I don't know how to safe differentiate case where function was
declared in .cc file and case when function is inline method declared in
header keyed to current compilation unit.  I don't want to output
unnecesary warnings for cases compiler can work out, so I need to look
into this first.

Honza
> 
> -- 
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713