This is the mail archive of the
mailing list for the GCC project.
Re: [patch] Statement operand iterators
> > > 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 :-)