Re: FOR_EACH_RTX

[Jan Hubicka <jh at suse dot cz>]

> But it's ugly. :-(
Yes, it looks.  But at least with new preprocesor, that reports lines
properly in macro parameters, this is very simple to use.
> 
> The stack-based speedups you can gain simply by implementing that
> approach, rather than recursion, in for_each_rtx.  If you can measure
> a noticable speedup, then that makes sense.
That was my original intention, but then I found, that using macro
has one extra advantage - mainly you can keep data in local variables.
This is very handy and avoids ugly using of globals(as we do in many places)
or the data structure.

My separate patch just makes for_each_rtx to use FOR_EACH_RTX.

So especially if you are looking for something tiny, such as presence of
register or so, the FOR_EACH_RTX construct looks much more readable,
since you simply do
FOR_EACH_RTX (insn, x, if (x == look_for) found=1, !found);
instead of packing that in separate function.

I agree that it is mater of style and I've expected this to be much worse
too, but it don't seems to be now.

Last advantage is presence of PUSH macro, that let you do much smarter
traveling that for_each_rtx is able to do.
> 
> Then, make for_each_rtx inline if we're compiling with GCC (as in
> stage2 and subsequent stages).  Then, if the compiler doesn't do what
> it should, improve the optimizers. :-)
Avoiding penalties for data packed in the structures or globals can be
tricky.
> 
> I would much prefer this approach rather than the massive macro thing.
Shame that we can't use other language here with more massive abstraction.

Honza
> 
> --
> Mark Mitchell                   mark@codesourcery.com
> CodeSourcery, LLC               http://www.codesourcery.com