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>
On Aug 25, 2008, at 4:03 PM, Devang Patel wrote:>> >> 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.It is not clear to me which should override which. For instance, instance, if I compiled with -Os or -O3 then I am forcing the codegen model at compile time, and the function IR would have the appropriate opt-size or opt-speed note. But if I specify neither at llvm-gcc time, the function IR should have neither opt-size or opt-speed note. At LTO time, I could specify -Os or -O3 (or equivalent) and it would make sense that the optimizer would use the opt-size or opt-speed from each function if there, or if none, inherit the default optimization goal from the link line. -Nick
On Aug 25, 2008, at 11:02 PMPDT, Nick Kledzik wrote:> On Aug 25, 2008, at 4:03 PM, Devang Patel wrote: >>> >>> 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. > > It is not clear to me which should override which. > > For instance, instance, if I compiled with -Os or -O3 then I am > forcing the codegen model at compile time, and the function IR would > have the appropriate opt-size or opt-speed note. But if I specify > neither at llvm-gcc time, the function IR should have neither opt-size > or opt-speed note. At LTO time, I could specify -Os or -O3 (or > equivalent) and it would make sense that the optimizer would use the > opt-size or opt-speed from each function if there, or if none, inherit > the default optimization goal from the link line.I think an explicit specification at LTO time should override whatever's in the input IR. I suggest this rule: whatever option was specified latest in the build process wins. In practice I don't think we'll see many intentional conflicting specifications. A design goal should be to make it hard to produce them unintentionally.