On Tue, Sep 14, 2010 at 3:36 PM, Basile Starynkevitch
<bas...@starynkevitch.net> wrote:
> Hello All,
>
> I was thinking of adding a new plugin hook for builtins.
>
> The intuition is that some plugins could be pleased if they could add
> their own plugins (much like today's plugins can add their own pragmas
> or attributes).
>
> I imagine several use cases for such a feature, for example
>
> * a builtin which generate at compile time a random number, e.g. for
> hashing purpose. [this could also be delt by preprocessor magic,
> for instance giving the ability for plugins to extend the behavior
> of libcpp by adding new plugin-specific predefined macros like
> __COUNTER__, so we could have a __RANDOM__ macro which would
> expand, at cpp expansion time, to a random number. From what I
> understood adding new predefined macros from plugins seems harder
> than adding num builtins]
>
> * a builtin which calls a foreign function in some language
> implementation (e.g. SBCL Common Lisp or native Ocaml) which have
> incompatible calling conventions w.r.t. of those of GCC
>
> * a builtin which simplifies a call to some complex external
> function into something simpler. __builtin_printf seems already to
> do that, and I could imagine many other cases.
>
> * a builtin to help a precise garbage collector by flushing every
> live variable (which might have been declared with a special
> attribute) out of registers.
>
> * etc...
>
>
> My intuition, by first looking into the gcc/builtins.c file, is that
> it is mostly a matter of providing a way for the plugin to register
> its plugin specific builtins into some hashtable, and then having the
> expand_builtin of gcc/builtins.c end with some code similar to
>
> case BUILT_IN_FREE:
> maybe_emit_free_warning (exp);
> break;
>
> default:
>
> {
> /* the pointer to an expander provided by a plugin. */
> rtx (*plugin_builtin_expanderfun) (int, tree, rtx, rtx);
> plugin_builtin_expanderfun = find_plugin_expander_for (fcode);
> if (plugin_builtin_expanderfun)
> {
> target = plugin_builtin_expanderfun (fcode, exp, target, subtarget);
> if (target)
> return target;
> }
>
> /* just do library call, if unknown builtin */
> break;
> }
>
> /* The switch statement above can drop through to cause the function
> to be called normally. */
> return expand_call (exp, target, ignore);
> }
>
>
> I actually intend to code something more flexible, by having plugin
> able to register a builtin expanding function with some client data.
>
> But is the overall idea enough, or did I misunderstood builtins?
Builtins use a fixed code (in DECL_FUNCTION_CODE) and have
a class (BUILT_IN_MD, BUILT_IN_NORMAL, etc.). Thus without
making the code assigning dynamic this won't work.
> Could such a small patch be accepted before end of stage 1?
No. We don't want new plugin hooks without an implemented use-case.
Richard.
> Cheers
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
>
