Re: identifing free() in tree-ssa

[Jan Hubicka <jh at suse dot cz>]

> Roger Sayle <roger@eyesopen.com> wrote on 02/01/2007 23:30:45:
> 
> > 
> > 
> > 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! :-)]
> >
> 
> [this is from Olga, not from Razya, my machine just passed away...]
> 
> Just an idea I thought about: if issue of compile-time so important, we 
> can make the construction of built-in functions to be flags-dependent, 
> i.e. for example, if flag of struct-reorg optimization is passed to 
> compilation line, and this optimization requires free () function 
> recognition, the __builtin_free will be constructed; otherwise it won't. 
> The change will require definition of new macro in builtins.def: 
> 
> #define DEF_LIB_BUILTIN_COND(ENUM, NAME, TYPE, ATTRS, COND)        \
>   DEF_BUILTIN (ENUM, "__builtin_" NAME, BUILT_IN_NORMAL, TYPE, TYPE,    \
>                true, true, false, ATTRS, true, COND)
> 
> and adding new line 
> 
> DEF_LIB_BUILTIN_COND        (BUILT_IN_FREE, "free", BT_FN_VOID_PTR, 
> ATTR_NULL, flag_ipa_reorg_structs)
> 
> and all other builtins definitions in builtins.def can be left unchanged. 

One idea I was playing with is adding some infrasrtucture for declaring
the builtlins lazily.  DEF_BUILTIN might just register builtin
constructor in static array consulted by frontend, but it is overall
little bit tricky to implement.  But limiting us in number of functions
to recoginze is bad in longer term.

Honza
> 
> Olga
> 
> > 
> > Roger
> > --
> >