Handling Command-Line Options in LTO

Design Considerations

This design is driven by a simple key observation:

Minor observations are:

Function Level Attributes

Depending on the LTO model, individual functions may move around from one IR file to another. This allows two design choices:

  1. Functions have the information from command-line options which didn't directly manifest in the IR available as function attributes. For example, fp relaxation rules are consumed by various backend optimizations, but have no representation in the IR itself.
  2. Do not move around (or inline) functions between files, if they have conflicting option settings. For example, do not inline a routine compiled with strict fp rules into a function with relaxed fp. Allow the other way round.

Option 2 appears simpler to implement and understand.

In regards to Option 1, specifying options explicitly for a function should be implemented, as it would allow building up more sophisticated infrastructure for exploratory search for performance potential, as well as automated bug triaging.

In the following, this assumes that function level attributes can be specified explicitly, and that such specification overrides other settings.

File Attributes

The command line options used to compile a whole file should additionally be stored in the resulting IR file, see below. Accessor functions to the actual string should be provided, as the options might need to be copied to the LTRANS invocations later.

Conflicting Command Line Options

Command-line options may conflict. If one IR file was compiled with -O2 and one with -O3, which optimization level should LTO use? Which optimization level should be used by LTRANS?

The rules for WPA

The rules for LTRANS

None: lto/OptionHandling (last edited 2009-01-27 20:41:11 by DiegoNovillo)