throw(), pure and const flags on functions

Jan Hubicka hubicka@ucw.cz
Tue Apr 14 13:54:00 GMT 2009


> Hi,
> > Hi,
> > I am trying to improve quality of IPA analysis of C++ code and I tend to
> > run into issues with amount of code we generate for EH and also amount
> > of calls to library.
> > It seems that PURE and CONST attributes in general are not used in
> > libstdc++ headers and there are also some cases where I think throw ()
> > marker is missing, like in _Rb_tree_increment.
> >   
> well, to be honest I'm not that enthusiastic about the idea of adding
> attributes in a lot of different places everywhere. In general, in this
> area, I would have expected a smooth progress in the compiler, gradually
> becoming able to discover on its own more and more pure, const, and not

With pure-const reorg, GCC is relatively able in discovering function
properties now (main limitation is being fact that it is unable to prove
finiteness of cyclic control flows even in most stupid cases and problem
with local Eh handlers. I plan to work a bit on both problems). However
it can do the job only as long as it actually sees them and it knows it
is safe.

We do worse on pure/const, but for nothrow and tramp I now can track
the reasons down to few cases: new() call, apply() call, rB tree manips
I mentioned in original mail and bultin_va_start I already sent patch
for.  It looks like only new() is valid reason. This is of course just
one special case for libstdc++ use ;)

Since library implementes a lot of basic datastructures that should be
fast and well optimized across.  These falgs would help.

For shared library we won't be able to derive this ourselves even with
LTO since these are in fact part of ABI too.  So we IMO should decorate
the functions implemented in libstdc++ library itself (not the headers).

As I've mentioned, I can add warning and I planned it to output only in
cases
 1) Function is visible outside TU so other TUs not seeing function body
 would degreade
 2) It is the case were we can't solve halting problem well.
    In many cases, like linked list traversals, it never will be and it
    is pity we can't handle those well.

And there is also attribute cold that would help a lot profile estimate
if used well.

Honza



More information about the Libstdc++ mailing list