[LLVMdev] Proposal : Function Notes

[Devang Patel]

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?


yes.

> 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
>> LLVM
>> 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.

-
Devang

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