SSA Iterators

Martin Sebor msebor@gmail.com
Fri Jan 31 07:37:00 GMT 2020


On 1/30/20 2:59 AM, Jonathan Wakely wrote:
> On Thu, 30 Jan 2020, 05:44 Nicholas Krause wrote:
>>
>> Greetings,
>>
>> I was looking into starting to cleaning up the SSA trees for various
>> reasons and iterators
>> seem to be the easiest to do. I searched the list to see if someone
>> mentioned it before
>> and I ran across this:
>> https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02031.html
>>
>> If your trying to get a second ++ working then why not override it
>> prefix as your
>> just doing it for postfix and those can be separate.
> 
> No no no.
> 
> No.
> 
>> Its not ideal to
>> have two
>> different versions for prefix and postfix in terms of overloading but it
>> may be
>> the simplest solution here.
> 
> No, making pre-increment and post-incrememt so different things (i.e.
> iterate over different ranges) is a horrible idea. That's the kind of
> thing that gives operator overloading a bad name. Overloaded operators
> should do the thing you expect them to. They should not be used to
> hide a non-obvious action behind an apparently simple syntax.
> 
> 
> I would suggest avoiding "smart" iterators that contain all the state
> and know their own end point. Instead create a type that holds all the
> state and has begin/end member functions which return an iterator that
> refers to the state. And have the iterator  dereference to some other
> object that has the state for the second level of iteration, with its
> own begin/end members returning the second iterator type. That would
> end up looking like:
> 
>    imm_use_stmt_range r (SSAVAR);
>    for (imm_use_stmt_iter it = r.begin (); it != r.end (); ++it)
>      for (imm_use_on_stmt_iter it2 = it->begin (); it2 != it->end (); ++it2)
>        ;
> 
> At some point when we move to C++11 or later that could become:
> 
>    imm_use_stmt_range r (SSAVAR);
>    for (auto& stmt : r)
>      for (auto& on_stmt : *stmt)
>        ;

That's a good goal to aim for with all GCC "iterators," including
those behind the legacy FOREACH_XXX macros.  I posted a patch for
one of these in 2018 but it was too late in the development cycle
and I didn't get back to in in 2019:
   https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01549.html

If you're working on a general cleanup in this are please consider
these as well.

Martin



More information about the Gcc mailing list