[LLVMdev] Proposal : Function Notes

Devang Patel dpatel at apple.com
Mon Aug 25 14:13:38 PDT 2008

On Aug 25, 2008, at 1:12 PM, Dan Gohman wrote:

> From this description, it sounds like this particular problem is that
> users just aren't accustomed to passing their "optimization" options
> to the compiler during the "link" phase. Is there more to it than  
> that?

Yes.  The issue is that optimization/code generation choices for  
various input IRs at link time may not match.

> Otherwise, this sounds like a problem best solved in documentation
> and IDEs.
>> The Inliner
>> The GCC compiler supports inliner specific attributes, e.g. noinline,
>> always_inline. These attributes instruct the inliner to take special
>> actions for
>> the function that specifies them. This information is not properly
>> encoded in
>> LLVM IR, which means the llvm inliner is not informed about such
>> special
>> requests, for example always_inline. Today, llvm-gcc respects GCC’s
>> noinline
>> attribute but the current solution is not ideal.
> We already have attributes like "noreturn". Can you discuss what the
> main advantages are of using this new notes mechanism instead of just
> adding more function attributes like the ones we already have?

Right now we have parameter attributes. NoReturn is implemented as a  
special case parameter attribute, which is not idea. Initially we  
named this proposal as function attributes then later on we realized  
that this is not specific to GCC's function attributes.

> Would unsupported notes be rejected in the Verifier?


> Can the names directly correspond with the current -mattr names
> somehow? It'd be good to avoid inventing yet another subtarget
> minilanguage :-).

Fine with me :)

>> The Function Notes are not a place for all the llvm-gcc command line
>> options.
>> Each note should represent function specific choice or an option for
>> passes. For example, optimize for size is appropriate because it
>> instructions
>> the LLVM passes to make appropriate choices and update their
>> thresholds. It is
>> appropriate to encode -ffast-math related choices here. It is not
>> appropriate
>> to include -O4 as a function note.
> What's the fundamental difference between -Os and -O4 here? Why is one
> appropriate for a note and the other not?

-Os is specific - Optimize for size. The llvm pass can make  
appropriate decision, e.g. update their thresholds, based on this note.

-O4 is useful for the tool that is arranging pass sequence.  
Optimization level 4 is defined and documented at llvm-gcc level, it  
has no meaning at llvm IR level.

> Also, if you're going to put -ffast-math in a note, please include in
> this proposal a description of what happens when a -ffast-math  
> function
> is inlined into a -fno-fast-math function, or a -fno-fast-math  
> function
> is inlined into an -ffast-math one.

We are in unchartered territory thanks to LTO! What happens today,  
without Function Notes, when user does following ?

$ llvm-gcc -c -ffast-math foo.c -O3 --emit-llvm -o foo.o
$ llvm-gcc -c -fno-fast-math bar.c -O3 --emit-llvm -o bar.o
$ llvm-gcc foo.o bar.o -o foobar -O4

We will have to make appropriate decisions when the LTO merges notes  
from different compilation units and document them properly.


> Also, how about all the various
> individual options that -ffast-math is an umbrella for?

More information about the llvm-dev mailing list