On Tue, 14 Sep 2010 11:21:51 -0600 Marcus Daniels <mdani...@lanl.gov> wrote:
> On 9/14/10 10:58 AM, Basile Starynkevitch wrote: > >> It seems to me a "source to source" compiler should definitely retain > >> high level constructs like array operators, DO ALL, OpenMP directives, etc > > One can use #pragma-s& builtin-s& attributes for these. This is why I was > > trying to push the idea of plugin hooks for builtins. > In this use case, what is the GCC middle-end *for* if it does not > understand data parallel operations? Even GENERIC lacks the notion, > right? (We've been working directly from the Fortran parse tree.) > The GCC middle end use is for me mandatory (since it is contractual). I am expecting to work on Gimple to OpenCL translation, whatever that means. The saling point it that starting from GCC & gimple gives the hypothetical enduser all the power of GCC. I cannot answer precisely more today to that question. However, Albert Cohen, IIRC, told me that some future improved Graphite-type polyhedric optimisation might perhaps help. My builtin plugin hook was from the intuition that to make such parallel operations, I'll probably need some _Pragma-s & builtin-s (very suitably hidden in macros or whatever). I'm just trying to figure out what are the features in 4.6 which will be useful to my work. I know that in a couple of weeks, they are frozen (since 4.6 is ending stage 1). The gengtype patch series http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01029.html I am trying to push with Jeremie Salvucci is also almost needed for MELT (and for any plugin using GTY). I have no idea if it will make into 4.6, because I still don't understand which *reviewer* is interested by them. So my current feeling is that within a two year timeframe, no more plugins hooks (even small ones like the builtin hooks I was thinking about) are possible in practice. This is probably bad news for my work, but I will have to do without! I am apparently the only one thinking that there are not enough plugin hooks [the popular opinion being that there are too much of them; I am in the minority against that opinion], and that they structure wisely the GCC programming interface. Besides plugins hook have at least a tiny documentation, which most of GCC API don't have yet. I really do not understand the philosophy of: work hard for one or two years making a plugin, and the GCC community will perhaps eventually consider -and only after the work is completed- adding the tiny hook which would have saved you 6 months of work. [I am speaking of course of small hooks which can be incorporated into the trunk by a single small patch and which have no measurable effect on GCC performance when not used] Some nice people privately emailed me that plugin don't catch since they are disabled by many Linux distributions (however it seems to me that Ubuntu/Maeverick, i.e. the future 10.10 currently in beta, has GCC 4.5 with plugins enabled and provide even a gcc-4.5-plugin-dev package, and so does Debian/Sid which is the real source of many Ubuntu packages), but I cannot understand how plugins could catch if adding a small hook is nearly impossible. This is a typical chicken & egg situation or catch-22. 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 mine, sont seulement les miennes} ***
