Re: gengtype: conditional GTY ? (to add before GCC 6 release)

[Richard Biener <richard dot guenther at gmail dot com>]

On February 12, 2016 3:55:33 PM GMT+01:00, Mikhail Maltsev <maltsevm@gmail.com> wrote:
>
>On 02/12/2016 04:38 PM, Richard Biener wrote:
>
>> Sorry, no.  The plugin API was never considered stable and thus
>plugins have to
>> deal with incompatibilites as they arise.
>> 
>> Help with picking up the partially completed work on a stable plugin
>> (introspection) API
>> is of course welcome.
>> 
>> Richard.
>
>When I had to write a rather simple plugin for GCC, it seemed very
>convenient to use C++11 range-based for loops instead of GCC's
>FOR_EACH_... macros, so I created several helper classes.
>
>For example (for GCC 5.x) after implementing:
>
>class const_stmt_iterator {
>public:
>    const_stmt_iterator(const_basic_block bb, gimple_seq* seq,
>gimple_seq_node node);
>
>    const_gimple operator*() const;
>    const_stmt_iterator & operator++();
>    bool operator == (const const_stmt_iterator &other);
>    bool operator != (const const_stmt_iterator &other);
>private:
>    const_basic_block m_bb;
>    gimple_seq* m_seq;
>    gimple_seq_node m_node;
>};
>
>class each_stmt_bb
>{
>public:
>    each_stmt_bb(const_basic_block bb);
>    const_stmt_iterator begin() const;
>    const_stmt_iterator end() const;
>private:
>    const_basic_block m_bb;
>    gimple_seq *m_seq;
>};
>
>
>Now, instead of
>
>gimple_stmt_iterator gsi;
>for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
>  {
>     gimple stmt = gsi_stmt (gsi);
>     ...
>  }
>
>one can write (in C++11):
>
>for (gimple stmt : each_stmt_bb(bb))
>  {
>     ...
>  }
>
>Likewise, instead of:
>
>basic_block bb;
>FOR_EACH_BB_FN(bb, fn)
>  {
>     ...
>  }
>
>C++11 users can write:
>
>for (basic_block bb : each_bb(*fn))
>  {
>     ...
>  }
>
>The problem is that iteration protocol is significantly different
>between various collections in GCC. And none of them (IIRC) use C++
>begin/end iterators.
>
>Even without altering GCC sources I could provide some sort of wrapper
>library, which will make life easier for plugin writers. 

The intention of the introspection (and eventually instrumentation) plugin API was to provide a stable API wrapping around GCCs internals.  The API was supposed to be compiler neutral (if you can implement it for both GCC and LLVM I would consider it neutral enough).

There were several half-finished approaches providing those.

Unfortunately,
>as I understand, GCC developers are not motivated to accept refactoring
>of iterators into GCC codebase, because more concise range-based for
>loops are only available in C++11 (and as David Edelsohn told me, there
>are no plans to migrate to C++11 because we need to keep compatibility
>with some old compilers :( ).

Yep.

>Nevertheless, I think using idiomatic C++ iterators and ranges in GCC
>is
>good because:
>1. They decouple iteration logic for the object (i.e. if basic_blocks
>for some reason will no longer store prev/next pointers, all
>FOR_EACH_BB_ loops will need to be changed; this is not the case, if we
>have separate iterators for them).
>2. Such iterators will allow to use range-based for loops for plugins
>without additional libraries.
>3. C++98 limitation is hopefully not forever :).
>
>What do you think about refactoring iterators in GCC 7?

I think refactoring towards STL style iterators would be welcome.  It may be different for the actual instances though.

Richard.