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?
Could such a small patch be accepted before end of stage 1?
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} ***
