Re: identifing free() in tree-ssa

[Basile STARYNKEVITCH <basile at starynkevitch dot net>]

On Tue, Jan 02, 2007 at 02:30:45PM -0700, Roger Sayle wrote:
> 
> I think recognizing "free" as a built-in (without an intrinsic) is the
> correct way to go.  In theory, all of the functions listed in
> cp/cfns.gperf should be defined via builtins.def, but unfortunately
> the compile-time (and memory) overhead of constructing a large number of
> builtins at run-time is already noticeable.  Hence, we only define
> those that are most useful [even though I'd like to optimize away calls
> to qsort where n is a compile-time constant zero or one! :-)]
> 
> If anyone has any ideas on how best these builtins can be constructed
> statically and/or lazily, conveniently for those front-ends that can
> benefit from them, I'd be very interested in suggestions.  

Maybe, instead of using built-ins, we could extend the __attribute__
facility for functions (and expect the libc developers to progressively use
them). Eg

   void free(void*) __attribute((pointer_invalid(1)));

would mean that argument #1 of function free is pointer which is invalidated
by the function. Or maybe a pragma for that....

Of course, the challenge is then how to have lots of attributes, and not
slow down the compiler... I don't?know yet if adding hundreds on definitions
inside gcc/builtin-attrs.def would slow down the compiler.

IMHO, adding new attributes would permit future library developers to
annotate their header files appropriately. This would be more powerful than
understanding only a given standard symbol like free. Of course, the cost of
attributes is that to use them?effectively we depend upon library developers
using them actually in their headers.

Happy new year 2007 to everyone.



-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/ 
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***