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,

> > here is the reimplementation of the idea.  The thing now uses macros in
> > such a way that gcc is able to determine in compile time which type of
> > operands is accessed.  The macros make it a small bit harder to use --
> > the example I used in the first mail would now be written as
> >
> > oii oi;
> > FOR_STMT_OPERANDS (&oii, stmt, OI_ALL_USES,
> >   {
> >     code;
> >   });
> >
> > with the negative effects of this type of macros (hard to
> > debug, impossible to use #ifs in code); but at least (unlike
> > EXECUTE_IF_SET_IN_BITMAP macro) `break' in code will work as expected.
> >
> > On the other hand, it no longer causes any measurable slowdowns.
> 
> Macros which take compound statements as arguments are trouble -
> mainly because the preprocessor doesn't count braces when looking for
> the close paren.  I would strongly encourage you to implement this in
> a way that allows writing
> 
>   oii oi;
>   FOR_STMT_OPERANDS (oi, stmt, OI_ALL_USES)
>     {
>       code;
>     }
> I think you could achieve this by moving the bulk of the macros into
> oi_init and oi_next (which are inline, so there should be no
> performance hit).  

unfortunately this cannot be done; the performance penalty for having to
decide which type of operands you are accessing is too high (see the
previous incarnation of the patch that avoided the use of macros
completely).

Zdenek


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