gcc-c-api

[Michael Matz]

Hi David,

On Mon, 10 Sep 2012, David Malcolm wrote:

> Is it possible for you to post your work-in-progress code somewhere?

Attached.

> I know that you don't feel it's ready for committing, but I would find 
> it helpful - I'm interested in understanding the general approach, 
> rather than seeing completeness or perfection.

Some sort of brain dump follows:

The idea is as follows: as first cut an introspection API that is tied to 
compiler IR concepts rather than GCC specifics.  As such it should be 
implementable also for other compilers, at least the trivial things that 
every traditional compiler will have.  So, we have functions, basic 
blocks, instructions, operands and operators.  Nothing of that should 
relate to tree or gimple or RTL.

Take for instance the (included) dump-plugin.  The goal would be, that 
depending on where you'd put that dumper in the pass pipeline it would 
work _unchanged_ on GENERIC, on GIMPLE and on RTL.  That goal isn't 
reached yet, once because the internal iteration just isn't
implemented for e.g. RTL instruction stream, and once because the operand 
iterator API isn't well suited to the tree-like nesting in GENERIC and 
RTL currently.

[The intermediate goal was to redo the operand API to be tree-like at the 
base, and possibly write small wrappers to again expose the nicer 
interface that GIMPLE would provide (i.e. direct access to all read 
operands of an instruction).]

Another thing I want is simplicity.  E.g. only the bare minimum of types 
should be exposed.  Note how the API itself for instance doesn't expose 
different types of collections, only a general Range which can enumerate 
all things, depending on how it's used (though the implementation has 
runtime checks for wrong usage).

There are some questions to be solved, e.g. memory management for those 
objects that aren't directly tied to GCC objects, e.g. Ranges right now.  
I do have a strong feeling about the relation of e.g. plugin Instructions 
and GCC gimple/rtx, in the sense that plugin authors should _not_ be 
required to manage memory for those things (same for BBs, functions, 
operands).

There are also other things missing: e.g. operators.  The current thing 
doesn't have access to the TREE_CODE/gimple_expr_code/RTX_CODE, and hence 
can't differ between an add and a mul.  Obviously that's less than 
optimal.  But the codes exposed for the plugin should have no relation to 
GCC codes, but again be general concepts.  So, externally the plugin would 
export codes like "GCC_ADD/SUB/MUL", whose enum values will remain stable 
forever, and internally they're mapped from the tree/rtx codes (that 
mapping can changes as we add/remove some enum values from those).

Also types aren't included.  Though some things would be obvious: a 
gcc_type (Operand op) function, and some accessors like "gcc_arithmetic_p 
(Type)", "gcc_width (Type)", "gcc_unsigned_p (Type)" and so on.

Obviously most useful accessors to the individual objects are missing. 
Those accessors again should be fairly unrelated to GCC specific concepts, 
but I would envision things like "gcc_volatile_p (Instruction i)" or 
perhaps "gcc_reg_p (Operand)".

> In particular, as the maintainer of the gcc-python-plugin I want 
> something that will make my life easier.

Well, the current version 0.0 certainly will not make your life easier.  
It misses almost everything ;)  But my goal was to set a ground interface 
that I would be pleased to work with as plugin author, _and_ that is 
easily maintainable by GCC authors (in a way this is actually more 
important), with the hope that actual plugin authors would extend it 
according to above principles as they need.

> By that I mean: something that will make it easier to keep my plugin 
> compatible against "as many gcc versions as possible" (which currently 
> means 4.6 and 4.7, but I want to add 4.8 and so on), and minimize the 
> amount of recompiling I have to do over ABI issues within a GCC release.  

Yes, that's definitely the goal of my approach.  Few opaque types, few 
high level accessors, never to be changed again (ABI wise) in the future, 
...

> My plugin is currently implemented in C (requiring C++ would be a pain 
> for me, but would be doable, I think).

... and the API C only, yes, definitely.

I hope the above made some of the principles clear, even though the actual 
implementation is terribly lacking in features.


Ciao,
Michael.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-pluginapi-0.0.diff
Type: text/x-patch
Size: 10337 bytes
Desc: 
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20120910/d4aabae9/attachment.bin>