[patch] Statement operand iterators

[Andrew MacLeod]

> > 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.

ie

#define SUI_USE	sui_use

#define FOR_EVERY_STMT_VIRTUAL_USE(STMT, CODE)
     do {
        unsigned int sui_x;
        use_operand_p sui_use;
        vuse_optype vuses = STMT_VUSE_OPS (STMT);
        v_may_def_optype v_may_defs = STMT_V_MAY_DEF_OPS (STMT);
        for (sui_x = 0 ; sui_x < NUM_VUSES (vuses); sui_x++)
          {
	    sui_use = VUSE_OP_PTR (vuses, sui_x);
            CODE;
          }
        for (sui_x = 0 ; sui_x < NUM_V_MAP_DEF_OPS (vuses); sui_x++)
          {
            sui_use = V_MAY_DEF_OP_PTR (vuses, sui_x);
            CODE;
          }
     } while (0)

then your loop looks like:


  FOR_EVERY_STMT_VIRTUAL_USE (stmt,
    {
      code (SUI_USE)
    });

Or something like that.

So you end up with 3 or 4 macros for the things you care about. There
would be no performance impact for this.

Andrew