On Tue, Sep 14, 2010 at 10:12:18AM -0400, Diego Novillo wrote: > On Tue, Sep 14, 2010 at 09:36, Basile Starynkevitch > <bas...@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} ***
