Re: GCC gprof statistics

[Zack Weinberg <zack at codesourcery dot com>]

Ishikawa <ishikawa@yk.rim.or.jp> writes:

> With gcc 3.3, I have already done the three specializations of
> functions that call the generic for_each_rtx.
> This reduced the compilation time by
> 0.2 seconds from 9.3 sec to 9.1 sec.
> about 2 percent speedup...
>
> Three specialized functions are:
> for_each_rtx_approx_reg_cost
> for_each_rtx_check_dependence
> for_each_rtx_check_for_label_ref
> In view of Andrew's suggestion that for_each_rtx could
> be improved, I probably should create a generic macro
> to define such specialized functions. 

This is a good technique, but one must take care not to bulk up the
code space.  for_each_rtx is small enough that it is okay.  There are
hairier functions (walk_tree comes to mind) where the tradeoffs will
probably run the other way.

> Looking at canon_rtx, I was under the impression that maybe we must do
> something radical to RTX data structure, but as the post from Adnrew
> suggests that micro-analyzing and doing various small optimizations
> can probably achieve more speedup without major surgery.
> canon_rtx probably can be tuned.

Geoff Keating and Richard Henderson have been talking about a much
more compact RTL form that looks like traditional N-address code:
instead of 

(insn X Y Z 
   (set (reg:SI 24)
        (add:SI (reg:SI 25)
                (reg:SI 26)))
   {addsi3}
   annotations)

you'd have

(insn X Y Z {addsi3} [ (reg:SI 24) (reg:SI 25) (reg:SI 26) ]
   annotations)

This is very much blue sky, alas.

zw