Re: Builtins and C++ and such

[Mark Mitchell <mark at codesourcery dot com>]

--On Tuesday, March 19, 2002 10:53:46 PM +0000 Jason Merrill 
<jason@redhat.com> wrote:

> I think special gunk in the compiler is necessary;

Why?  (Not meant to be a rhetorical question; I'm curious.)

Certainly, __builtin_memcpy is necessary -- but why gunk to turn
memcpy into __builtin_memcpy?  Isn't that something the library
headers can do for you, at least in C++ where you *had* to have
a declaration?  Do we really care about people who manually write
the declaration themselves?

> Roger Sayle has talked about yet another scheme, esentially the current
> predeclaration strategy, but using DECL_ANTICIPATED_P to determine whether
> or not a decl is visible to normal lookup; see the threads starting with
>
>   http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01628.html
>   http://gcc.gnu.org/ml/gcc-patches/2001-12/msg00297.html
>
> More simply, the three differ in when the lookup is done and the
> attributes are applied:  at startup, at the declaration, or at the call.
>
> I'm still partial to my own scheme; a builtin doesn't exist in the symbol
> table until a matching function is declared, and then the information is
> available in the DECL for as many calls as desired.

Of the various in-the-compiler schemes, my priorities would be:

1. Changes that are safest: i.e., least likely to result in
   non-conforming and/or suprising results.

2. Changes that support multiple languages.

3. Changes that are easy to make, and self-contained.

My beef with DECL_ANTICIPATED_P, and maybe your scheme, involve all
of these problems: you have to remember to check DECL_ANTICIPATED_P,
and you don't really know where all the places are, it doesn't do
anything for you in Java or other languages, and, since there are
multiple places to change, you have to change them all.

Changes way in the back end (say, a pass over RTL) bother me because
they assume C bindings: if you're in language Foblotz and in Foblotz
memcpy means printf, and you have a Foblotz library that does the
right thing, and the compiler changes memcpy into a builtin, your
Foblotz program will get miscompiled.

My present suggestion is allegedgly good because it uses a little
hook that all languages can take advantage of in whatever
way they want, it delays the optimization until RTL expansion so
that tree-based optimizations don't get confused, and it is pretty
demonstrably safe by looking at the body of the hook and nothing
else.

Do you buy it, assuming we have to go this way?

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