After checking in the patch to provide unique pass names for all passes, I created
svn://gcc.gnu.org/svn/gcc/branches/ici-20091108-branch and merged in the patches from: http://gcc-ici.svn.sourceforge.net/svnroot/gcc-ici/branches/patch-gcc-4.4.0-ici-2.0 Could you please check that this contains the functionality that we want to integrate in the first step. FWIW I know that the code does not conform to the GNU coding standard yet. I've changed register_pass to register_pass_name to resolve the name clash. I'm not sure if it should be called register_pass_by_name or something else, opinions welcome. Both the gcc 4.5 code and the ICI patches have the concept of events, but the implementations are so different that the functionality is pretty much orthogonal. 4.5 has a real C-style interface with an enum to identify the event and a single pointer for the data. I.e. low overhead, but rigid typing, and the different parts of the program presumably find their data by virtue of using the same header files. Multiple plugins can register a callback for any event, and all will get called. However, since the set of events is hard-coded by an enum declaration, you can't have two plugins communicating using events that the gcc binary doesn't know about. The ICI events feel much more like TCL variables and procedure calls. Events are identified by strings, and parameters are effectively global variables found in a hash table. This is very flexible and can allow a good deal of ABI stability, but costs a lot of processor cycles as before an event call the parameters are looked up to be entered in the hash table, and afterwards they are looked up to be removed, even if no callback is registered for the event. Also, when a plugin registers a callback for an ICI event, it overrides any previous callback registered by another (or even the same) plugin. I think we could have the ICI event flexibility/stability with lower overhead if the event sender requests an event identifier number (which can be allocated after the numbers of the gcc 4.5 static event enum values) for an event name at or before the first event with that name, and then sends this identifier number with one or more pointers, which might point to internal gcc data structures, and a pointer to a function to look up the address of a named parameter. The event sender site source code can then provide information to build the lookup functions at build time, e.g. using gperf. I.e.: /* Call an event with number ID, which is either a value of enum plugin_event, or a number allocated for a named event. If the event named parameters, the first parameter after id should be as if declared void * (*lookup_func) (const char *, va_list) . LOOKUP_FUNC can be passed the name of a parameter as its first argument, and a va_list as its second argument, which will be the list of parameters after LOOKUP_FUNC, to find the named parameter. */ void call_plugin_event (int id, ...) { struct callback_info *callback; va_list ap; gcc_assert (id < event_id_max); callback = plugin_callbacks[id]; va_start (ap, id); for (callback = plugin_callbacks[id]; callback; callback = callback->next) (*callback->func) ((void *) ap, callback->user_data); va_end (ap); }
