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

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

On Wed, Apr 15, 2009 at 5:34 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> 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.

Well, the reason I'm pointing this out is that there are
influencial people in the C++ community who make claims
tthat 'throw()' is to be discouraged because it makes compilers
generate worse code.  You are claiming to the opposite, that is
why the issue is so important.


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

I'm not suggesting that the compiler should accomplish miracles
for things it knows nothing about.  However, I'm also unimpressed
that one has to annotate both versions of _tree_increment
(for example),
when both are visible to the compiler and the compiler knows
that one just forward to the other.  That suggests to me that the
compiler heuristics need to be refined.

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

OK.  How is it that one needs to annotate both versions
of _tree_increment?

>
> Honza
>