On February 12, 2016 3:55:33 PM GMT+01:00, Mikhail Maltsev <malts...@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.
