llvm dev - Jan 2013 - [LLVMdev] [cfe-dev] RFC: Codifying (but not formalizing) the optimization levels in LLVM and Clang

On Mon, Jan 14, 2013 at 4:46 AM, Justin Holewinski <
justin.holewinski at gmail.com> wrote:
> If I understand the attributes correctly, they would be function-level
> attributes applied to IR functions, correct?  I'm curious what the
> semantics would be for cross-function optimization.  For example, consider
> a function "foo" defined with maxopt and a function
"bar" defined with
> optsize.  If foo() calls bar() and the inliner wants to inline bar() into
> foo(), is that legal?  If so, that may cause odd effects as you may perform
> expensive optimizations later on the inlined version of bar(), even though
> the original function is marked optsize.
>
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.

>
> Also, a nit-pick:  can we make the naming consistent?  It feels a bit
> weird to have maxOPT and OPTsize.  Perhaps use sizeopt and minsizeopt, or
> optmax and optquick?

Meh. I don't care really. It would require changing existing attributes,
but we can do that. I think the most readable structure is the first:

minsizeopt
sizeopt
quickopt
opt
maxopt

I'd like to hear some support for one or the other of these before deciding.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130114/2828bf59/attachment.html>

Chandler Carruth <chandlerc at gmail.com> writes:
> minsizeopt
> sizeopt
> quickopt
> opt
> maxopt
I prefer being consistent and putting "opt" at the end.

I would still like something other than "opt" for the fourth one. 
"opt"
seems too generic given the other levels.

                             -David

On Mon, Jan 14, 2013 at 1:30 PM, <dag at cray.com> wrote:
> Chandler Carruth <chandlerc at gmail.com> writes:
>
> > minsizeopt
> > sizeopt
> > quickopt
> > opt
> > maxopt
>
> I prefer being consistent and putting "opt" at the end.
>
> I would still like something other than "opt" for the fourth one.
"opt"
> seems too generic given the other levels.
>
I agree that having just "opt" seems too generic in comparison. Maybe
something like "stdopt" (or even the longer "balancedopt")
since it
corresponds to -O2 and is intended to represent a good optimization level
for most cases with a balance of compile time, space, and runtime
efficiency.

- Kaelyn
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130114/b5c00d3f/attachment.html>

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.

-Krzysztof


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

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>