[LLVMdev] Proposal : Function Notes

[Nick Kledzik]

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

-Nick

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