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} ***
