🚀 go-pugleaf

The Computer Language Operation at Hewlett-Packard would like to get your
opinions on command line options to control optimization.

If you would like to respond, please Email your reply to "dr@cup.hp.com",
by January 22, 1993.  Please do not post a reply.  We appreciate your feedback!

Note: you do not need to be an expert at optimization to provide useful
feedback. 

The following note presents two different proposals for command line options 
to control optimization, and then asks some questions on what you would prefer.
We would like to get your feedback on whether either of these is an
improvement over the current command line option syntax for invoking
optimization, on the HP9000 series 700 and series 800 computer systems.


-------------------------  Proposal 1 starts here ---------------------------

This proposal offers an increasing level of choices, depending on how much
you want to control the optimization process.


First choice:

  Your first choice is whether you want to optimize or not, the choices are:

   Option        Meaning
   ------        -------

    <none>       No optimization.

     -O          Basic Optimization.

  The optimizations performed under the basic "-O" level were chosen to
  provide a good balance -- they increase run-time execution speed
  without excessively slowing down compile time and link time.

  The "-O" level is not the highest optimization level available, but
  it is a good choice for many users.  It is equivalent to "+O2" below.


Second choice:

  There may be times when you want more or less optimization than
  available through the basic "-O" level.  For this, this proposal
  offers the following (brackets indicate the letters between the
  brackets are optional, and a vertical bar means you can choose one of
  the two choices):

    +O1[s]           Level 1 provides optimization that compiles very
                     quickly, but still provides some execution-time
                     speedup.  Level 1 optimizations are those that the
                     compiler can do in a few passes of looking at the
                     generated instructions.

    +O2[c|a][u][s]   Level 2 (which is equivalent to "-O") takes more
                     time to compile, but produces greatly improved
                     run-time speed.  At this level, the compiler does
                     extensive analysis of data-flow, memory usage,
                     loops, and expressions.  Level 2 includes all
                     optimizations that can be done while considering
                     only one source file at a time.

    +O3[c|a][u][s]   Level 3 goes a step beyond level 2, by postponing
                     optimization and code generation until link time.
                     This allows the optimizer to process the entire program
                     at once (at link time).  By doing this, the optimizer 
                     can take advantage of execution profile information
                     to do a better job of improving the object code.
                     Also, it can shorten global data references and do
                     inlining across multiple source files.  Postponing
                     optimization until link time decreases the time
                     spent in the compile phase, but it greatly increases 
                     the time and memory required to link the program.

    Level 3 includes all the optimizations of level 2.  Level 3 is not
    included in the set of optimizations done at the basic "-O" level, because 
    of its large increase in the time and memory required to link a program.

    The level number controls where the optimizer spends its time:
      Level 1 is very quick optimization on one file, 
      level 2 is extensive optimization on one file, and 
      level 3 is extensive optimization over the entire program.

    The optional letters that follow the level number control other
    aspects of optimization.  These are as follows:

    Letter        Meaning:

      c           Conservative optimization.  This reduces the level of
                  assumptions the optimizer makes about the code, so that 
                  the optimizer can correctly optimize source code even
                  when that source code violates the strict definition
                  of the language.  Run-time performance will be less
                  then the default level.

    <no letter>   Basic optimization (default) -- those optimizations at
                  each level that do not change the behavior of code
                  that conforms to the applicable language standards
                  (for each particular language).

      a           Aggressive optimization.  This raises the level of
                  assumptions the optimizer makes about the code, doing
                  things that might be risky to gain the best possible
                  run time performance.  This also includes optimization
                  techniques that are new for this release.

      u           Unrestricted compile time and compiler memory space --
                  does all optimizations appropriate to the optimization
                  level without regard to compilation time and memory
                  space.  By default, compilation time and space are
                  limited when optimizations are performed on large routines.

      s           Optimize for Space.  This letter disables optimizations 
                  that expand the size of the executable program.  Most 
                  optimizations improve both execution time and reduce
                  code space.  This option suppresses the few techniques
                  that expand code space to improve execution time.

  Example:  To produce the best run time performance (and the longest
            time to compile), use "+O3au".


Third choice:

  Most of the time, using level 1, 2, or 3 optimizations with their
  suboption letters should provide you with the control over the
  optimizer that you need.  Additional parameters are provided when you
  require a finer level of control.

  At each level, you can turn on and off specific optimizations using the  
  +O[no]<optimization> option.  The <optimization> parameter is the name 
  of a specific optimization technique.  The optional prefix [no] 
  disables the specified optimization. 

  There are many such toggles, here is just one example:

    +O[no]pipeline  Enables [or disables] software pipelining.  The default is 
                    +Opipeline at levels 2 and 3 unless the [s] suboption is
                    specified.  The +Opipeline option replaces the obsolete
                    "+OS" option.

  Several advanced optimization options can be specified in the same command 
  line.  For example, the following command line specifies aggressive level 3
  optimizations with unrestricted compile time, disables software pipelining,
  and disables moving conditional floating-point instructions out of a loop:

       cc +O3au +Onopipeline +Onomoveflops sourcefile.c

  Specify the level of optimization first (+O1, +O2, or +O3), followed by
  any +O[no]<optimization> options.

  There will be a new mnemonic toggle to replace many of the obscure 
  optimization options HP currently supports (-J, +OE, +Om1, +OV, +Obb, etc).

------------------------  Proposal 1 ends here -------------------------------
------------------------  Proposal 2 starts here -----------------------------


This section proposes an alternate way of controlling optimizer
aggressiveness, compile time, and code-expansion.  This proposal groups
the optimization features into four levels and eliminates the "a", "c",
"s", and "u" suboptions.  Advanced toggles to enable or disable specific
optimization techniques (such as "+O[no]pipeline") would be provided
with this proposal, just as they are provided in the other proposal.
The options would appear as follows:

Option             Aggressiveness   Compile Time    Code Expansion 
---------------------------------------------------------------
+O1                conservative     very limited    enabled
                   (not likely to change unstructured code)

-O or +O2          basic            limited         enabled
                   (not likely to change unstructured code)

+O3                aggressive       unlimited       enabled 
                   (not likely to change standards-conforming code)

+O4                very aggressive  unlimited       enabled
                   (may change the behavior of user's code
                   in areas such as error handling)

With each higher level of optimization, there is an increase in the risk
and build times, as well as potential performance benefits.  At level 3
and level 4, optimizations are performed at link time.

The major differences between this proposal and proposal #1 are:

1) This proposal emphasizes a simpler command line interface, in that
   there are no suboption letters.  It thus offers 4 choices, instead of
   the 24 possibilities offered by proposal #1.

   This proposal thus bundles all factors together on one scale.  When
   optimizing the entire program at link time (level 3 and 4) it makes
   the most aggressive assumptions about the object code.  When optimizing
   one file at a time (level 2), it will only do basic optimization.
   No other combinations are possible.  For example, you cannot request
   aggressive optimization on one file, nor conservative optimization
   over the entire program.

2) In contrast to proposal #1, this one offers two "aggressive" levels.
   The first would be for new optimizations, and the second "very
   aggressive" level would be for optimizations that can change program
   behavior (for example:  changing error handling methods, or moving
   floating point exceptions).

3) The "s" (size) suboption is not provided since optimized code is
   typically about 50% smaller than unoptimized code, and suppressing
   space expanding optimizations would typically only reduce the size of
   an average program by another 3% to 5%.  If a customer wants to limit
   the object code size, he or she could turn off any optimizations that
   increase code size, by using the toggles, as follows:

      cc +O4 +Onoinline +Onolibcall +Onopipeline sourcefile.c

4) The "u" (unrestricted) suboption is not provided since this proposal
   assumes that optimization is typically performed only at the tail end
   of projects, and because limiting compilation time when optimization
   is enabled is not a major issue for most customers.

5) The "c" (conservative) and "a" (aggressive) suboptions are not
   provided as they are replaced by placing more aggressive optimizations 
   at the higher optimization levels.

------------------------  Proposal 2 ends here -------------------------------

After reading through the proposals, please answer the following questions:

1) Briefly describe your programming environment.
   Languages:                  
   Platforms: 
   Applications:
   # of years of programming experience: 
   Standards Conformance (ANSI, NON-ANSI, POSIX, X,...):

2) Do you currently use the HP optimizer? If so, what command line options?



3) Are the proposed optimizer schemes easy to understand?  Which one is
   easier to understand?  Is there anything in either scheme that is not
   straightforward?



4) Do the proposed optimizer schemes provide the capability you need? 
   If not, what is missing?


5) Which proposal do you prefer?



6) Is the ability to control the actions of the optimizer (in terms of
   aggressiveness, compile time limits, and code size) important to you?
   

 
7) If you are already using the HP optimizer, is either of the proposals
   an improvement?



8) What optimization options might you consider using?

 

9)  What other comments do you have regarding optimization command
    line options?



10) May we contact you to obtain more information about your use
    of the HP optimizer?



We appreciate the time you have taken to read and comment on these
proposals.  We plan to incorporate any feedback received into planning
for our next product release cycle.