On 06/21/2012 03:59 PM, Joshua Cranmer wrote: > On 6/21/2012 8:17 AM, Tobias Grosser wrote: >> On 06/20/2012 11:58 PM, Joshua Cranmer wrote: >>> diff --git a/docs/ClangPlugins.html b/docs/ClangPlugins.html >>> --- a/docs/ClangPlugins.html >>> +++ b/docs/ClangPlugins.html >> >> Hi Joshua, >> >> I am not a regular contributor to clang, but I am following the plugin >> infrastructure development and I must say I like the general >> direction. My use case are no frontend plugins, but a plugin to drive >> the Polly optimizer. What I would like clang to support is: >> >> - Allow the insertion of linker flags such as '-lgmp' from a plugin >> - Allow the insertion of '-mllvm -flag' style parameters to change the >> LLVM default behaviour. >> - Shorter plugin parameters in the style of -<plugin-name>-<argument>. >> E.g. '-polly-vectorize'. >> >> I know this is not the goal of this patch, but this gives the context >> from which I look at it. > > This patch in particular is primarily intended to introduce a plugin API > which is feature-compatible with the -load/-plugin-add setup, with the > exception that running plugins in lieu of regular code generation is an > explicit nongoal (there's always libtooling or -fsyntax-only for that). > That said, I do intend to add more features to plugins eventually. The > ones I'm currently planning on working on: > 1. Letting plugins add custom pragmas/attributes > 2. Letting plugins do a more intrusive modification of the optimization > passes run > 3. Letting plugins modify the command lines for the jobs run by the > driver (which includes, e.g., adding linker flags) > > I also want to see the ability for plugins to modify the AST to be able > to, e.g., add instrumentation that requires knowledge of the original > C/C++ due to lossiness in IR representation, but I already know I'm not > qualified to do this.
Great to get an update on the general direction here. I like it a lot, but will now stop the discussion to allow us to focus on the review of this patch. I did not state it before, but from my side it looks good style and typo wise, but I am by no means familiar with clang and can consequently not review it. >> Like the runtime check for the plugin version. It is definitely a step >> forward. However, do you know what happens if some function names in >> clang changed and the plugin still references old function names? I >> suppose this will still give a linker error when loading the plugin. >> So even so this is going in the right direction, it may be nice to >> reason in future patches about a solution that gives a clear error >> message in that case. > > Er, I hadn't thought of that. Yes, it is actually not so easy to solve. If you find a solution, it would be great if it could also be applied to the LLVM plugins. >> Sounds good. Do you think at it will be possible in later patches to >> add hooks to change the linker flags or the -mllvm flags? > > Yes, it's possible, but there's an issue in that clang is separated in > two processes (the driver and cc1). Given that the plugin is initialized > and loaded in the cc1 process (since that's where most of the > interesting stuff happens), to make it work would require another entry > hook (for the driver), and would probably cause a few issues for people > who rely on static constructors/destructors running exactly once. I was looking into this myself and it seems non trivial. Still, I think it would be nice to have. Looking forward to see your further work Tobi _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
