Hi Joern,
> 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.
Thanks a lot, Joern!
I downloaded it and will be gradually checking it.
In the mean time, Yuanjie, Liang and Yuri - could you check this version ASAP
and check that the functionality provided during GSOC'09 developments/pass
reordering
work is correct in this version!.. The reason is that since there will be some
small
changes, our plugins will have to slightly change as well (see register_pass
change)...
By the way, we should keep the track of such changes on the GCC Wiki for ICI ...
> 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.
I think register_pass_by_name will be better to show what it does now ;) ...
> 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.
That's very true. Our current idea is that for prototyping of ideas, it is
often fine to slow down the compiler slightly but as soon as development
matures and there are some interesting results, the developers will try
to persuade the GCC community to add the event permanently...
> 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);
> }
I have been discussing that with Zbigniew some months ago and I think it can be
reasonable
to add such functionality on top of current ICI. ICI users will still prototype
their ideas
using events referenced by name, however if it works fine and before potential
lengthy approval
to get such an event, they can speed up their plugins using this extended
functionality...
The good thing is that their plugins will still be compatible if we will decide
to keep associated
names with the hardwired event number ...
Cheers,
Grigori
