Chris Lattner <[EMAIL PROTECTED]> writes: > On Sep 19, 2008, at 3:25 PM, Ian Lance Taylor wrote: > >> Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes: >> >>> I am much more worried about passes and plugins (and I am very >>> surprised to be almost the only one mentioning passes in plugin >>> discussions). I feel it is a major issue (not a matter of coding, >>> much >>> more a matter of convention & understanding). So far, I have (in MELT >>> branch) a very unsatisfactory bad solution. I defined a few passes, >>> which may (or not) be enabled by some plugins. What I would dream is >>> some machinery to be able to have the plugin ask 'insert my pass >>> foo_pass after the last pass which construct the IPA SSA tuple >>> representation' and this is not achievable today. >> >> I think we also need that for general backend use, not only for >> plugins. E.g., bt-load.c should move to config/sh, and at startup >> time the SH backend should register the pass with the pass manager. > > Is the plugin machinery intended to eventually allow new (GPL > compatible) backends to be used? It would be nice to make llvm-gcc be > a plugin.
As this point it seems likely that distributing a gcc plugin will effectively put the distributed code under the GPL. Of course this would not affect other versions of the code which were not distributed as a gcc plugin. I think the main focus of the plugin efforts is to permit inserting extra passes into gcc for various different types of analysis. But I don't see any reason that it would be impossible to insert an entirely new backend. The llvm-gcc plugin could more or less take the GIMPLE structures it had access to, do whatever it liked, and then exit. Ian
