Chandler Carruth
2013-Jan-14 22:57 UTC
[LLVMdev] [cfe-dev] RFC: Codifying (but not formalizing) the optimization levels in LLVM and Clang
On Mon, Jan 14, 2013 at 2:21 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote:> On 1/14/2013 3:23 PM, Chandler Carruth wrote: > >> >> This is a great question. My plan would be: inlining doesn't impact the >> attributes. The inliner will be free to look at both the caller and the >> callee's attributes to choose the best inlining decision. >> > > The problem is not so much with the inlining decisions, as much as it is > with keeping the attributes in the inlined code. If you have a function > foo, which is to be compiled at O2, and it's called from bar, whose > optimization level is O3, then you can take the O2 code and insert it in > the middle of the O3 code. The problem is that in certain cases, compiling > at O3 is not acceptable, so we can't just "upgrade" the opt level from O2 > to O3.OK, I hadn't realized that wasn't clear. I absolutely think that when a function has an optimization attribute, that applies to the code in the function and all code inlined into the function. If foo calls bar then foo's optimization level should be valid for bar, or bar should be marked noinline, or something else. I'm dubious about any kind of built-in way of controlling this because there shouldn't (in a perfect world) be any code which "isn't valid" at one optimization level, and if this is only about intent, then *if* the inliner made the right decision to inline, then the intent of the caller should apply to the inlined code. If it wouldn't apply, the inliner made the wrong decision. -Chandler -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130114/7692ff89/attachment.html>
Krzysztof Parzyszek
2013-Jan-14 23:22 UTC
[LLVMdev] [cfe-dev] RFC: Codifying (but not formalizing) the optimization levels in LLVM and Clang
On 1/14/2013 4:57 PM, Chandler Carruth wrote:> > I absolutely think that when a function has an optimization attribute, > that applies to the code in the function and all code inlined into the > function. If foo calls bar then foo's optimization level should be valid > for bar, or bar should be marked noinline, or something else.That's going way too far. For example, if a function foo, which can be compiled with -ffast-math calls bar, which contains code that would be "over optimized" with -ffast-math, then you cannot inline bar into foo, but you can inline it in any other function that does is compiled with the same options as bar.> I'm dubious about any kind of built-in way of controlling this because > there shouldn't (in a perfect world) be any code which "isn't valid" at > one optimization level,Should we wait until you see such situations then? ;) -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Chandler Carruth
2013-Jan-19 07:55 UTC
[LLVMdev] [cfe-dev] RFC: Codifying (but not formalizing) the optimization levels in LLVM and Clang
Sorry, I realized I hadn't replied to this. On Mon, Jan 14, 2013 at 3:22 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote:> On 1/14/2013 4:57 PM, Chandler Carruth wrote: > >> >> I absolutely think that when a function has an optimization attribute, >> that applies to the code in the function and all code inlined into the >> function. If foo calls bar then foo's optimization level should be valid >> for bar, or bar should be marked noinline, or something else. >> > > That's going way too far. > > For example, if a function foo, which can be compiled with -ffast-math > calls bar, which contains code that would be "over optimized" with > -ffast-math, then you cannot inline bar into foo, but you can inline it in > any other function that does is compiled with the same options as bar.-ffast-math is *totally* different from these attributes, and in fact -ffast-math is specifically not modeled as a function attribute because it changes the fundamental semantics of an operation. These attributes have zero semantic impact on the function, and so it is always functionally correct to change them, replace them, merge them, remove them, or inline code from one to the other. The question is only what is *desirable* given the optimization levels indicated by the attributes, and I think the desirable strategy is that the inlined code has the caller's attribute used when optimizing. The idea is that if a particular call site should be optimized according to X, then that call site after inlining should be as well, even if the function being called isn't (perhaps because there are many other callsites with different levels).> > > > I'm dubious about any kind of built-in way of controlling this because >> there shouldn't (in a perfect world) be any code which "isn't valid" at >> one optimization level, >> > > Should we wait until you see such situations then? ;)I think this is more of a theoretical invariant. If we discover such a situation is is likely either invalid code or invalid optimizations, not an invalid model. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130118/16e3f860/attachment.html>
Maybe Matching Threads
- [LLVMdev] [cfe-dev] RFC: Codifying (but not formalizing) the optimization levels in LLVM and Clang
- [LLVMdev] [cfe-dev] RFC: Codifying (but not formalizing) the optimization levels in LLVM and Clang
- [LLVMdev] [cfe-dev] RFC: Codifying (but not formalizing) the optimization levels in LLVM and Clang
- [LLVMdev] [cfe-dev] RFC: Codifying (but not formalizing) the optimization levels in LLVM and Clang
- [LLVMdev] [cfe-dev] RFC: Codifying (but not formalizing) the optimization levels in LLVM and Clang