Optimization for size

The pass manager builder has an option for Os (0, 1, 2). But all it
does, AFAICR, is to disable one explosive optimization pass.

I'm not sure how that gets propagated into the DAG. Maybe every
function in that module receives the attribute Richard mentions...

Optimization for size hasn't been tested properly, at least not for
ARM, and I hit all sorts of trouble (even before getting to DAG) when
enabling it.

-Os doesn’t actually exist for llc, and I can’t see an obvious place where
that condition would be set. Where do we specify if we’re optimizing for
codesize or performance?

The pass manager builder has an option for Os (0, 1, 2). But all it
does, AFAICR, is to disable one explosive optimization pass.

In clang/LLVM, -Os is not very different from -O2. It dials back inlining, and disables a few other optimizations. The idea is to reduce code size without sacrificing too much performance.

The -Oz option is supposed to do the same as gcc's -Os: Minimize code size at any cost. This option is not supported by the code generator yet.

I'm not sure how that gets propagated into the DAG. Maybe every
function in that module receives the attribute Richard mentions...

Exactly. This is so you can mix -Os and -O3 code in an LTO build.

Optimization for size hasn't been tested properly, at least not for
ARM, and I hit all sorts of trouble (even before getting to DAG) when
enabling it.

Bugzilla or it didn't happen.

/jakob

Optimization for size hasn't been tested properly, at least not for
ARM, and I hit all sorts of trouble (even before getting to DAG) when
enabling it.

Bugzilla or it didn't happen.

Optimization for size on ARM is more important than most other
platforms. It is still very common for embedded ARM cores to have
only 64 kb of Flash.

A couple friends of mine were two of Atari's first seven video game
coders. They had a choice of using 2 kb or 1 kb ROMs to store their
executables in. While 2 kb ROMs allowed for much easier to write and
more featureful games, they always strove to target the 1 kb ROMs
because they cost half as much to manufacture and so the coders would
earn twice as much in royalties.

It happened all the time that a game's executable size would get down
to just a few bytes over 1 kb. Despite their best efforts, the coders
could never get their executable to 1 kb or less, because doing so
would break the hard-coded timing loops. I understand that some
coders would go insane as a result.

My father had the same problems in some old machines (in the 70's),
where the only thing available (at all) was 2k or RAM. So they had to
split bigger programs in chunks of 2k and serialize the results in
tape (that took minutes to write, and could take hours to find/read).
There were some quirks to make it much faster, though, but I don't
remember the details...

Of course, there's no such thing as a compiler in these cases... :wink: