[LLVMdev] questions about LLVM code optimization

[Tim Northover]

Hi,

> I'm porting a llvm target to PIC14 like chip.
> the llvm's optimization is so remarkable, when I write a function which has
> never be called and has no side effect, the function will be deleted has no
> ASM output. but I just need a trivial function delay time.

It sounds like you're more concerned with the C level here, in which
case you should mark those functions with "__attribute__((used))".
This forces Clang to emit the function definition even if it thinks
it's not used (and as far as I can tell, LLVM won't then remove it).
It may still be inlined, of course, but that's a separate issue.

> also I need stop inline expansion and loop unrolling, ignore the inline
> keyword even.

Is your main concern code-size? If so, I'd expect the "-Oz" option not
to go unrolling loops (or doing inlining unnecessarily). It may solve
your problems without resorting to source-level annotations.

Otherwise, there is another attribute: "__attribute__((noinline))".
This one attaches the "noinline" function attribute to the LLVM IR,
which our optimisation passes then obey (hopefully).

> so the question this, how can I stop this optimization above? maybe some
> configure option can stop this when compile the llvm release?

There are various compiler options that help: -fno-inline-functions
and -fno-unroll-loops spring to mind, but they're probably the wrong
way to solve most problems. Usually it's not the actual inlining or
unrolling that you care about, but its negative effects in some other
area (code size, speed, ...), and using those options is rather
heavy-handed.

> and where is the source code doing this optimization in llvm source 3.3?

Various passes in lib/Transforms/IPO may or may not decide to inline
by the looks of it. It's not guaranteed that they'll all respect
-fno-inline-functions either (in particular the one for
__attribute__((alwaysinline)) probably won't).

The unrolling is also distributed. The actual code that does it seems
to live in lib/Transform/LoopUnroll.cpp (and neighbours) but
lib/Transform/Vectorize/LoopVectorize.cpp (may not be in 3.3) and
lib/Transform/Scalar/LoopUnrollPass.cpp can independently decide
whether or not to invoke it.

Cheers.

Tim.