pub struct Options {
pub level: OptLevel,
pub toggles: Vec<(String, bool)>,
pub fuel: HashMap<String, u32>,
pub global_fuel: Option<u32>,
pub gates: Gates,
pub dumps: Dumps,
pub verify: bool,
pub interposition: Pic,
}Expand description
What the command line asked the optimizer for.
Fields§
§level: OptLevelWhich pipeline to start from.
toggles: Vec<(String, bool)>The passes -f<name> added and -fno-<name> removed, in the order they were given, so
that the last mention of a pass is the one that decides.
fuel: HashMap<String, u32>What -fpass-fuel=<pass>=<n> limited, by pass name.
global_fuel: Option<u32>What -fpass-fuel-global=<n> limited the whole pipeline to, across every pass.
This is the outer search of the two in section 4.5 of
spec/optimizer/04-pass-manager.md. Halving this finds the pass, and halving
-fpass-fuel for that pass finds the rewrite inside it. Two searches of twenty
compilations each beat one search over a space nobody knows the shape of.
gates: GatesWhat -fdisable-<pass> and -fenable-<pass> said about which functions a pass runs on.
dumps: DumpsWhat -fdump-ir= asked to see.
verify: boolWhether the verifier runs after every pass that changed anything.
interposition: PicWhich definitions in this module something else may replace at load time.
The analyses that read a body and write down what they found have to stop at a name like
that, because the body they read is not the one that will run. Pic::Library is the
answer when the object may end up in a shared library and the exported names in it are
interposable, which is what -fPIC alone means and is gcc’s default.
Pic::Executable is the answer for everything else, and that includes
-fno-semantic-interposition, where the build has promised that the definition here is the
one that runs. It is a promise and not a deduction, and it is the one every distribution
makes, because a library that cannot inline its own functions into each other pays for the
possibility of an interposition that never happens.
This is not the same value the code generator is given. How an address is reached does not change under that promise, and gcc does not change it either: a variable a shared library exports is still read out of the global offset table, because the promise is about which definition runs rather than about how many copies of the variable there are.
Implementations§
Source§impl Options
impl Options
Sourcepub fn chosen(&self) -> Vec<&'static str>
pub fn chosen(&self) -> Vec<&'static str>
The passes the level and the -f flags chose, in order, before the gates are consulted.
A pass named by -f<name> that the level did not choose is appended, because the only
place it could go that does not need an ordering rule nobody wrote down is the end.
Sourcepub fn passes(&self) -> Vec<&'static dyn Pass>
pub fn passes(&self) -> Vec<&'static dyn Pass>
The passes that will run, in order, over at least one function.
A pass -fenable-<name> reached that the level did not choose is appended after them,
for the same reason and in the same place. It runs only over the functions the gate names,
which is the whole point of the flag: a pass being in this list is not the same question as
a pass running on the function somebody is looking at.