Well, we need to return values or even structures using plugins for our MILEPOST project to tune cost models. A simple example is loop unrolling: in our current plugin implementation (MILEPOST GCC/ICI) we register a plugin function that will predict loop unrolling and pass some code features to it (code size, etc) whenever loop unrolling is performed. Then the plugin communicates with the predictive model server (implemented in MATLAB) and returns a loop unrolling factor (as an integer). However, we will need to return more complex structures in case of polyhedral optimizations in GCC 4.4 (GRAPHITE) or other optimizations/code generation...
Cheers, Grigori > -----Original Message----- > From: Taras Glek [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 09, 2008 6:11 PM > To: Hugh Leather > Cc: Grigori Fursin; 'Brendon Costa'; 'Basile STARYNKEVITCH'; gcc@gcc.gnu.org; > 'Sean Callanan'; > 'Cupertino Miranda'; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Taras Glek'; > 'Diego Novillo'; 'Mike > O'Boyle' > Subject: Re: Defining a common plugin machinery > > Hugh Leather wrote: > > Aye up all, > > > > I think the env var solution is easier for people to use and > > immediately understand. There would be nothing to stop those people > > who don't like env vars from using the shell wrapper approach. Why > > not allow both? > I think the other replies addressed this question. I've updated the wiki > to reflect the consensus on env vars. > > > > Are you sure about this style of event/callback mechanism? It > > seems to scale poorly. Isn't it likely to be a bit inefficient, too? > > Through this approach, plugins can't cooperate; they can't easily > > define their own events and it feels too early to prevent that. > I'm trying to take the pragmatic approach. There are features we > absolutely need in GCC. The simplest possible solution is likely to be > accepted sooner. > The proposed API is not to become carved in stone. If it turns out 10 > years down the road we chose the wrong plugin API, I'm all for scrapping > it and replacing it with something more relevant. > > It looks like it's trying to replicate the abstraction of calling a > > function with something worse. What I mean is that I think what > > people would like to write is: > > GCC side: > > void fireMyEvent( 10, "hello" ); > > Plugin side: > > void handleMyEvent( int n, const char* msg ) { > > // use args > > } > > > > But now they have to write: > > GCC side: > > //Add to enum > > enum plugin_event { > > PLUGIN_MY_EVENT > > } > > // Create struct for args > > typedef struct my_event_args { > > int n; > > const char* msg; > > } my_event_args; > > // Call it: > > my_event_args args = { 10, "hello" }; > > plugin_callback( PLUGIN_MY_EVENT, &args }; > > Plugin side: > > void handleMyEvent( enum plugin_event, void* data, void* > > registration_data ) { > > if( plugin_event == PLUGIN_MY_EVENT ) { > > my_event_args* args = ( my_event_args* )data; > > // Use args > > } > > } > > > > Which seems a bit ugly to me. Although, it does have the advantage > > of being easy to implement on the GCC side. > This approach takes 5 more minutes of development time, that wont be a > noticeable difference in the long run. > > > > And, if they're replacing a heuristic and need a return value then > > even more lines of code are needed on both sides. How would this > > style work for replacing heuristics? > I don't know how heuristics work in GCC work. It is possible that these > handlers might need to return an integer value, but so far in my plugin > work I have not needed that so I didn't include return values in the > proposal. > > Taras
