🚀 go-pugleaf

In article <8960010@hpfcso.HP.COM> mjs@hpfcso.HP.COM (Marc Sabatella) writes:

| >> Well, there is also actually a strong *hint* that the variable will
| >> be heavily *dynamically* used across statement boundaries, in the
| >> current scope. The compiler can use this hint very effectively.
| >
| >Such a hint is only useful to an exceptionally dumb compiler.  Most
| >modern compilers do better data flow analysis than human programmers
| >are willing to do. Studies have shown that compilers can consistently
| >do a _very_ good job of register allocation without such hints.  In fact,
| >most C compilers simply ignore the 'register' attribute except to verify
| >that the variable is never used with an 'address-of' (&) operator.
| 
| Throw in profiling, and you've got a deal.  But very few compilers actually
| take profiling data into account, and if you've written a routine which takes
| a parameter 'n' that gives the iteration count for the loop, no amount of
| static data flow analysis (even interprocedural, in many cases) is going to
| tell you the dynamics of that loop.  Now say you have another loop, with a
| fixed count of "10".  Which should the optimizer think is going to be more
| heavily executed?  A careful programmer can hint to the optimizer with
| 'register' which variables he thinks are more important, which may be all the
| hint the compiler needs.  And often it doesn't take a lot of work to do this,
| so you are not "better off using assembly langauge".  There is also
| portability to consider.

The MIPS compilers seem to have the ability to use profiling data when
doing full blow optimization.  Here are some sections from the online
manual (from a Dec Pmin system):

Cc(1) man page section:

     -O3            Perform all optimizations, including global
                    register allocation.  This option must pre-
                    cede all source file arguments.  With this
                    option, a ucode object file is created for
                    each C source file and left in a .u file.
                    The newly created ucode object files, the
                    ucode object files specified on the command
                    line, the runtime startup routine, and all
                    the runtime libraries are ucode linked.
                    Optimization is performed on the resulting
                    ucode linked file and then it is linked as
                    normal producing an a.out file. A resulting
                    .o file is not left from the ucode linked
                    result.  In fact -c cannot be specified with
                    -O3.

     -feedback file Use with the -cord option to specify the
                    feedback file.  This file is produced by
                    prof(1) with its -feedback option from an
                    execution of the program produced by
                    pixie(1).

     -cord          Run the procedure-rearranger on the resulting
                    file after linking.  The rearrangement is
                    performed to reduce the cache conflicts of
                    the program's text.  The output is left in
                    the file specified by the -o output option or
                    a.out by default.  At least one -feedback
                    file must be specified.

Prof(1) man page section:

     -feedback filename
               Produces a file with information that the compiler
               system can use to decide what parts of the program
               will benefit most from global optimization and
               what parts will benefit most from in-line pro-
               cedure substitution (requires basic-block count-
               ing). See cc(1).
--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA

Catproof is an oxymoron, Childproof is nearly so