Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!snorkelwacker!paperboy!meissner From: meissner@osf.org (Michael Meissner) Newsgroups: comp.lang.misc Subject: Re: 'register' variables and other goodies (was Re: Common subexpression optimization) Message-ID: Date: 9 Feb 90 17:20:04 GMT References: <14226@lambda.UUCP> <8960010@hpfcso.HP.COM> Sender: news@OSF.ORG Organization: Open Software Foundation Lines: 75 In-reply-to: mjs@hpfcso.HP.COM's message of 6 Feb 90 16:12:40 GMT 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