Re: plugin hooks for plugin-provided builtins?

[Basile Starynkevitch <basile at starynkevitch dot net>]

On Tue, Sep 14, 2010 at 10:12:18AM -0400, Diego Novillo wrote:
> On Tue, Sep 14, 2010 at 09:36, Basile Starynkevitch
> <basile@starynkevitch.net> wrote:
> 
> > I was thinking of adding a new plugin hook for builtins.

> Plugin hooks should only be added when an actual need arises.  Adding
> hooks for the sake of adding hooks is not a good way to evolve this
> functionality.


Whatr do you call an actual need? I did gave some interesting use
cases for plugin providing builtins. Are'nt their enough? Should I
elaborate more?



I don't understand at all this "actual need" thinking. You seems to
suggest that first a real plugin should be developped which shows the
interest of a hook (and developping such a real interesting plugin is
a year's work at least), but this won't be a plugin, it would be an
entire GCC branch and won't be able to work as a plugin into any
future GCC, and then only the idea of adding such and such hook can be
considered.

I don't buy that way of thinking. What is the difference between doing
that and working on one's branch?


############


 My current work aims to translate some Gimple into OpenCL source
code, thus providing GCC with the ability to take advantage of GPU
running their proprietary OpenCL compilers without asking the user to
learn OpenCL. In principle the idea would be to generate some OpenCL
from Gimple, and Jeremie Salvucci experimented the idea of generating
plain C code from Gimple (his code is not fully working, but under the
GCC MELT branch file gcc/melt/xtramelt-c-generator.melt).  Generating
C code from Gimple could also help to use GCC [e.g. when compiling
Fortran] with opensource C code analyzers like Frama-C
http://frama-c.com so having plugins which spit Gimple into C is not a
stupid idea (and for sure that functionality will never make into core
GCC, it should stay as a plugin).

I am not in the position of understanding how the GPU processors work
internally in detail and writing a GCC backend for them (this is a job
for American people at AMD/ATI or Nvidia; it cannot be done in Europe
where no GPU are designed and where the internals of GPUs is an
American industry secret. However, OpenCL specification is public and
readable even in France).

However, the project [opengpu.net] currently funding me requires me to
be able to show a plugin [it actually will be a MELT module, not just
a plugin coded in C] which translates some code (using Gimple) in
OpenCL source code feeded to some proprietary (AMD or Nvidia)
implementation.

Very probably, I will need plugin-specific #pragma-s; we already have
hooks for them, and plugin-specific builtin-s (for instance, builtin
translated to code transferring data from the CPU to the GPU in my case).

Given that adding a hook for plugin specific builtin is simple, what
should I do concretely? We also have the dreadful end of stage 1 for
4.6 deadline in end of october! So I try to figure out what few hooks
are missing to be able to work ...

Remember that for geographical & political reasons all my GCC work is
more "source to source" that "source to machine" oriented. I don't
have the expertise, and I am not legitimate (internally in my CEA LIST
organization at least, and also w.r.t. of funding French government
agencies) to work on anything close to the target processor or silicon
in GCC.

So could you all explain what is an "actual need for plugin hooks" for
you? I don't understand you, so please take time to explain.

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