Hi Joern, > > I am a bit confused about your above example - you suggest to add > > this functionality on top of current ICI or substitute it? > > The idea was to replace it. The current event implementation has two > issues: > - It is very different from the existing GCC 4.5 events which makes it > confusing to have it side-by-side. I think if we can make the ICI code > more of a natural extension of the current event code, it would be more > likely to be acceptable. > - The parameter registering / unregistering and the event call itself > introduce a number of hashing operations which are performed irrespective > of the presence of a plugin. This makes these events intrusive if placed > in places with a high execution frequency.
Ok, thanks for the update. I will send you another private email asking for more tech. details to be sure that we are in sync before doing further changes in ICI ... > > If you want to substitute it, I personally disagree. We spent a very > > long time > > with many colleagues and real ICI users discussing how to simplify > > the usage of > > events for people who are not programming professionals, > > so I really prefer to keep the current structure as it is ... > > Were these discussions done face-to-face or on a news group/mailing list? > If the latter, could you point me where I can read up on the discussion > so that I better understand the issues involved. > Would these people who are not programming professionals both insert > event raising points as well as write event handling code? Well, it's a long story. I moved first prototype of ICI from Open64 to GCC in 2006 and then had discussions with Albert and Diego at one of the HiPEAC tutorials about having plugins in GCC. However, since it was a taboo for GCC at that time, I continued extending it in the MILEPOST project and within the HiPEAC network of excellence. We had multiple discussions during MILEPOST and HiPEAC face-to-face meetings and private mailing lists. Recent emails at GCC mailing lists and comparison of plugin systems at GCC Wiki are here: http://www.mail-archive.com/gcc@gcc.gnu.org/msg41368.html http://gcc.gnu.org/wiki/GCC_PluginComparison > If we would use C++, some things would get easier, i.e. we could have an > event class with subclasses for the separate event types, and then have > the parameter accessors be member functions. This would remove the need > to repeatedly type the event name when accessing the parameters. > However, it would require to build GCC with C++, so I'd say this > significantly reduces the chances of having ICI integrated into the > gcc mainline and having release GCC binaries shipped with the > functionality enabled. I didn't mean rewriting ICI in C++. I meant that we need to check that the functionality works (i.e. pass selection and reordering + fine-grain selection of optimization and function cloning for c++ programs) when using g++ ... > If plugin-side run time is not important, we can have register_plugin_event > as a wrapper for register_callback and use user_data to squirrel away the > event name and the actual callback function; then we can have a wrapper > callback function which sets a thread-local variable (can be non-exported > global inside the plugin as long as no threads are used) to the plugin name, > and make get_event_parameter use a dynamic function name lookup by stringing > together the event name with the parameter name. > This way, we could look the ICI interface on the plugin side pretty much > what it looks now, except that we should probably restrict the event and > parameter names to identifier characters, lest we need name mangling > to translate them to function names. > > I had a look at the adapt branch to gauge if the there is really a point for > having the varargs stuff, i.e. events with parameters that are not readily > available in a single struct. > The unroll_parameter_handler / graphite_parameter_handler events are somewhat > odd because they have a varying set of parameters. So they really have a list > of parameters. We could do this with somehing like: > invoke_plugin_va_callbacks (PLUGIN_UNROLL_PARAMETER_HANDLER, > "_loop.id", EP_INT, loop->num, > "_loop.can_duplicate_loop_p", > EP_UNSIGNED_CHAR, > ici_can_duplicate_loop_p); > And then have the plugin pick through the va_list. Or, if preferred, > have a helper function - possibly invoked implicitly by the ICI > infrastructure - go through the va_list and build the hash table of arguments > from it so that the current parameter query interface can be used. > In fact, we could use such a mechanism in general, so if we go back to > passing pointers to parameters instead of parameters, you'd have > backward > compatibility on the plugin side. > OTOH, does using pointers to parameters really make this interface easy to > use - it seems you had to use this to avoid type compatibility issues, which > are sidestepped by using a va_list. If we pass parameter values instead, you > could have a query function that tells you if a parameter is set. Possibly > also with a pointer argument to assign the value if the parameter is set. > tests if a parameter exists - if you like I need to think about that. Let's sync offline first since I didn't look at the ICI code for some time and have a few deadlines coming this and next week... > > > However, if it is the way to speedup slow prototype plugins and > > addition to ICI, > > it may be fine but I need to think about it more. > > Having a single call to invoke an event by number (even if it is a > varargs call) is certainly much faster than having all these > register_parameter / unregister_parameter calls, particularly in the > case that no plugin has registered a callback for the event. Sure. > > > In both cases, I think it is not critical for now and should be the > > second step > > after current ICI is synced with the mainline. However, suggestions > > from others > > are very welcome ;) !.. > > I thought you were hoping to push some ICI infrastructure into mainline > in time for 4.5 . In order to do that > - Time is of the essence. > - We should reduce the impact that ICI has on the rest of GCC. Agree. However, again, I don't see the impact of ICI on the rest of GCC now. I think oppositely is barely touches the internals, except the pass manager ... Again, let's sync offline ... Cheers, Grigori
