RE: Defining a common plugin machinery

["Dave Korn" <dave dot korn at artimi dot com>]

Taras Glek wrote on 09 October 2008 17:37:

> Grigori Fursin wrote:
>> 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...  
>> 
> So what would you propose we do about return values? Some sort of
> pointer, or a code suggesting that the caller look up a variable some
> where? Or should we just suggest using void*event_data to pass a struct
> with fields to be used as outparams(I like this idea as it means no
> changes are needed :)?

  Sounds like you're almost in need of a generic data marshalling interface
here.

  It would be really neat if you could figure out a way to specify these
structs and their values as RTX.  Any plugin API could then be passed an RTX
with all its args in a parallel, and could return an rtx likewise.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....