This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Statement operand iterators


Hello,

> > currently, we have operands of statements split into 6 different
> > cathegories, with a separate accessor macros for each of them.
> > In addition we have a completely separate way of accessing arguments
> > of phi nodes.
> > 
> > This means that if I for example want to run some code over all uses
> > of the statement (both real and virtual), it means that I first have
> > to check whether I work with a phi node, or with a normal statement,
> > and in the later case prepare three optype variables and for each of them
> > run a separate loop.  In total I need either to duplicate the code
> > four times, or create a function for it
> > 
> 
> Its pretty easy to hide that now behind a new macro. All uses now return
> a use_operand_p with that last set of changes I made.  So writing a
> macro to do 
> FOR_EVERY_STMT_USE (stmt, iterator, {code})
> would be pretty straightforward without going to a lot of extra hassle,
> and have very little impact on compile time.

I have tried that approach as well.  The problem is that you really need
too much flexibility.  The situations we need to handle are at least

* all uses
* all defs
* all real operands
* all virtual operands
* all virtual uses
* all virtual defs

and possibly other I am forgetting.

> > Given that this is a fairly common operation, this is way too much work.
> > This patch introduces operand iterators.  With them, I may solve the
> > above with simply writing
> > 
> > oii oi;
> > for (oi_init (&oi, stmt, OI_ALL_USES); !oi_end_p (&oi); oi_next (&oi))
> >   code (oi_op (&oi));
> > 
> 
> So this would look like:
> 
>   stmt_use_iterator sui;
>   FOR_EVERY_STMT_USE (sui, stmt,
>     {
>       code (SUI_USE (sui))
>     });
> 
> where SUI_USE simply returns the use_operand_p for the use.

This would not be that much faster.  In fact retrieving the
use_operand_p (or the operand directly; the oi_op operation) is the only
slow part, and implementing it as a SUI_USE macro would not help --
the slow part is to decide which of the use types you are working with
now.

You might have FOR_EVERY_STMT_USE give you directly the use_operand_p,
however, which would work somehow.  However, I personaly dislike macros
of this type, since they make the code hard to debug.

Zdenek


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]