Re: Builtins in `std'

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Jakub" == Jakub Jelinek <jakub@redhat.com> writes:

    Jakub> This way you have tight lock between g++ version and
    Jakub> libstdc++, because if g++ 3.1.5 decides to optimize
    Jakub> std::foo then it has to wait until libstdc++ changes it
    Jakub> headers.

But:

  - This is already how the library is coded.

  - The library ships with the compiler, so if we update the compiler
    we can update the library too.

I have objected to the GLIBC practice of coding various
statement-expression inline-assembly macros for standard library
functions -- but this is different.  Here, all the standard library is
doing is defferring the implemention of `std::foo' to `__builtin_foo',
a primitive provided by the compiler.  That's good: no knowledge is
duplicated in the library about how to implement `foo', but at the
same time the library can use 

The premise of your comment is that the compiler knows better than the
library -- but I'm not sure that this is so.  The dynamics are
different than in C, where users can invoke these functions without
having to involve the library at all.

    Jakub> As I already wrote, this is especially bad in the global
    Jakub> namespace, because there the library has hard time to take
    Jakub> care of all the global namespace functions. Like:

We already do not put these names in the global namespace.

    Jakub> #include <cstring>

    Jakub> using namespace std;

    Jakub> int foo () { return strchr ("abc", 'a') != 0; }

    Jakub> will not be optimized while if it is replaced by
    Jakub> std::strchr it will (although as soon as those builtins are

This one uses the one in `std', thanks to the `using', so it will be
treated just like `std::strchr'.  And the library can easily make
`std::strchr' call `std::__builtin_strchr' just as it does for
`std::fabs'.

In C++, there is no such standard function as `::strchr', and it would
be wrong to optimize it specially.  A user program like:

  char *strchr(const char *, int) { return 0; }

must be accepted, must not count as a redefinition of the `strchr' in
the standard library, must not result in errors about defining two
functions with the same type, etc.  I don't think such a function can
be `extern "C"', though.

    Jakub> removed from std namespace it will not be optimized either
    Jakub> - only a very fraction of builtins have the inline wrappers
    Jakub> around __builtin functions even in the std:: namespace).

Thanks for pointing out this issue.  I will add the __builtin calls
when I submit my patch.

Here's the bottom line:

  - The library must work when `-fno-builtin' is supplied on the
    command-line.

  - In order to do that, it must provide a definition for all 
    of these functions in `std::', since with `-fno-builtin' the 
    compiler does not insert them.

  - There is no way for the library to know whether `-fno-builtin'
    has been supplied or not, so it must use a definition that
    will work all the time.

  - There's no reason for the library not to generate good code
    in this case, so it should be calling the equivalent `__builtin'
    from it's `std::' implementation of these functions.

Essentially, all the patch I have will do is hardwire flag_no_builtin
to true in C++.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com