This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Proposed gcc plugin plugin API mk 2 (this time without camel case!)
- From: ludovic dot courtes at inria dot fr (Ludovic Courtès)
- To: gcc at gcc dot gnu dot org
- Date: Thu, 12 Apr 2012 15:11:30 +0200
- Subject: Re: Proposed gcc plugin plugin API mk 2 (this time without camel case!)
- References: <1333387282.2447.60.camel@surprise>
Hi,
(Sorry for the delay.)
I suppose the proposed API doesnât cover all the needs of your Python
bindings and their applications, does it? How do you plan to export the
GIMPLE and tree.h APIs?
Regarding iterators, there are things like:
GCC_IMPLEMENT_PUBLIC_API(bool)
gcc_cfg_for_each_block(gcc_cfg cfg,
bool (*cb)(gcc_cfg_block block, void *user_data),
void *user_data)
{
int i;
for (i = 0; i < cfg.inner->x_n_basic_blocks; i++) {
Instead of the callback API, could the details of the containers be
exposed a little more, like:
/* Return the number of basic blocks in CFG. */
unsigned int gcc_cfg_block_count (gcc_cfg cfg);
/* Return a pointer to the array of basic blocks in CFG. */
gcc_cfg_block *gcc_cfg_blocks (gcc_cfg cfg);
That would allow higher-level language bindings to provide idiomatic
ways to iterate over basic blocks, such as (lazy) list iterators.
WDYT?
Thanks,
Ludoâ.