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

[Jan Hubicka <hubicka at ucw dot cz>]

> Paolo Carlini wrote:
> 
> > I see. Remember to "uglify" always "uglify" in the library, thus it
> > would be _ATTRIBUTE_PURE, or something like that, with an underscore at
> > the beginning. Indeed, we have a place for those things,
> > include/bits/c++config, should be ok.
> 
> I'd go so far as to suggest __GLIBCXX_PURE, but that's of course a call
> for the libstdc++ maintainers to make.  I'd try to use as small a chunk
> of the macro namespace as possible...  Do macros get expanded inside
> attributes?  If so, can we use "__attribute__ ((__pure__))" instead of
> "pure"?
> 
> Jan, I'd also love to see performance figures about how much this helps.
>  As always with optimizations, I'd like more quantitative data.  Here,
> it's not so important since there's no downside I can see, but it would
> still be fun to know that this actually does something valuable. :-)

Those few nothrow on RB trees saves about half of all EH control flow of
tramp3d, that is about 12000 EH edges. No runtime difference since all
the EH happens outside hot spots, but the EH code accounts over 20% of
tramp3d binary, so savings are noticeable too. I didn't get much more
data than that, but I can always commit stuff to pretty-ipa first to see
overnight C++ benchmark results.

I don't have any good EH heavy benchmark at hand now.  All C++
benchmarks we have so far are mostly about "if you get it right, you
will see mostly no EH at the end" kind of benchmarks.  All the benchmarks
basically have no explicit catch statements and all the EH is about
implicit cleanup regions produced. I wonder if some kind of stuff like
mozilla or something similar can serve as good benchmark of code that
actually does some nontrivial EH.

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