Re: [patch] Statement operand iterators

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

> > > There are a multitude of ways of implementing them, this is just an
> > > example of one which is pretty straightforward.
> > 
> > and about as slow as the iterator one; this version really has only
> > disadvantages compared with it.  The problem is really that the iterator
> > encompasing different types of operands must decide which one of them
> > to provide.  You can provide directly use_operand_ptr (then you can just
> 
> Then write a custom one for each one your truly care about. Your numbers
> were a 4-5% decrease in compile time, and that isnt worthwhile for what
> you get in return, IMO.
> 
> 
> > duplicate the code in the macro), but this does not work in case you are
> > interested in both uses and defs in the same time (which is not that
> > common, so we might live with that);
> 
> I would cetainly think its uncommon enough to not want to care about it.
> > but in any case those macros would be huge and ugly.
>  
> Custom ones thats arent trying to generalize would not be that bad, and
> besides, its hidden. You main motivation is so that you dont have to
> write the individual loops yourself.  Custom macros would solve that and
> not have any performance impact.

but still there is problem with debugging code using such a macros (you
cannot step individual statements in the code, you cannot put
breakpoints to them, etc.).

I agree that the slowdowns of the iterator solution of mine are not
acceptable, and I will probably implement the macro solution; but I would of
course be much happier if someone came with some solution that would be
both nice and friendly to use, and fast :-)

Zdenek