[LLVMdev] Proposal : Function Notes

[Devang Patel]

On Aug 25, 2008, at 3:24 PM, Nick Kledzik wrote:

>
> On Aug 22, 2008, at 4:40 PM, Devang Patel wrote:
>
>> The LLVM passes are responsible to take appropriate actions based  
>> on Function
>> Notes associated with function definition. For example,
>>
>> define void @fn1()  notes("opt-size=1") { ... }
>>
>> The function fn1() is being optimized for size without losing  
>> significant
>> performance. The inliner will update inlining threshold for fn1()  
>> such that the
>> functions called by fn1() are checked for size threshold for fn1()  
>> while being
>> inlined inside fn1(). If the function fn1() is itself inlined  
>> somewhere, for
>> example bar(), then the inlining threshold for bar() will be the  
>> deciding factor.
>>
>> define void @fn2()  notes("opt-size=2") { ... }
>>
>> The function fn2() is aggressively optimized for size. The code  
>> generator may
>> sacrifice performance while selecting instructions. The inliner  
>> will aggressively
>> reduce inlining threshold.
>>
>> define void @fn3() notes("noinline") { ... }
>> define void @fn4() notes("always_inline") { ... }
>> define void @fn5() notes("noinline,always_inline") { ... }
>>
>> Here the inliner is instructed to not inline function fn3()  
>> anywhere and inline
>> function fn4() everywhere. The function fn5() is malformed and it  
>> should be
>> rejected by the verifier.
>
> Since you opened the door with values for opt-size,  couldn't we do  
> the same for inlining.  That is:
>
>   define void @fn3() notes("inline=never") { ... }
>   define void @fn4() notes("inline=always") { ... }
>
> Then the general rule is that there can be only one "foo=" in the  
> set of notes.

yes!  I did not think about this. This is a good idea.

>   I know this won't make the __attribute__ keywords, but it would  
> make the function notes cleaner.
>
> Also, could there be a name for 1 and 2 on opt-size?   What happens  
> when we find a need for a third kind of opt-size...
>
>
> These seem like great default parameters for code-gen, but looking  
> forward, if we also allowed some optimization flags to be specified  
> at LTO time, how would they interact?

The flags specified on the linker command line during LTO are not  
encoded into llvm IR. However, IMO,  these linker command line flags  
should override notes encoded in llvm IR. We may have to handle  
special cases, but we should document linker's decision choices  
properly.

-
Devang


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080825/4f23b1ed/attachment.html>