RE: [plugins-ici-cloning-instrumentation] new GCC plugin developements

[Joern Rennecke <amylaar at spamcop dot net>]

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);
}