plugin hooks for plugin-provided builtins?

[Richard Guenther]

On Tue, Sep 14, 2010 at 3:36 PM, Basile Starynkevitch
<basile@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} ***
>