[llvm] r189101 - Add function attribute 'optnone'.

[Duncan Sands]

Hi Andrea,

>> Attribute optnone was originally intended to be used mainly for debugging
>> purposes.
>> Our customers almost exclusively use optimized builds because unoptimize
>> builds are too slow for their purposes, but the debug experience on
>> optimized builds is very often not good enough. Applying attribute optnone
>> to a function would allow the user to debug that function as if it were an
>> unoptimized build but having the rest of the program fully optimized. With
>> this use case in mind, I originally decided to make the 'optnone' behavior
>> similar to -O0.

it sounds like you want GCC's recently added -Og.  Sorry to say this, but
optnone sounds like a bad way to solve this problem to me.  Personally I
think you should remove optnone and instead work on improving the
interaction between the -O1 optimizers and debug info.  Mqybe if optimization
levels become an attribute attached to functions, then we could have a
-Og attribute and teach the optimizers not to do optimizations that unavoidably
play badly with debug info.  But for the moment -O1 is the closest thing we have
to -Og.

For what it's worth I agree with Nick that it should be possible to get the
optnone effect without introducing optnone into LLVM at all, by playing games
with the pass manager.  It does seem like a painful way of doing it though.

Ciao, Duncan.

>
> Thank you! Finally I understand the motivation behind "optnone" well enough to
> make informed decisions about its design!
>
> Firstly, the real way to fix this is to solve the optimized+debugging
> experience, but of course that's not happening any time soon enough. You need
> something now, but it does point out that maybe optnone isn't something we want
> to have in llvm forever -- it's just a workaround for a worse problem.
>
> I think you can build this out of existing pieces, or optionally with a couple
> of extensions. The frontend needs an 'optnone' attribute. When codegen'ing such
> a function, it should apply the 'noinline' attribute to it, and also to each of
> the call or invoke instructions that it contains.
>
> In LLVM, you need to control two pieces. Your frontend already controls the pass
> manager, at least to the extent that its API will permit. If you don't want to
> run module passes or CGSCC passes, you can just iterate over the list of
> functions and skip the functions you don't want to optimize and just run over
> the other ones. Or you could make a small extension to add a "skipFunctionList"
> to the pass manager, but really you can make that yourself: remove the
> function's body from the function before running the pass manager. Yep. Splicing
> a functions's blocks into a parentless function will leave a declaration in
> place in the module at the same pointer address. Then you put it back after
> you've run the IR-level pass managers. It's even an O(1) operation.
>
> Finally, you also need to ensure that the backend emits at -O0. The
> TargetMachine stores some options (TargetOptions) on a per-function basis. Make
> the codegen opt level one of those. (This may be somewhat difficult, you could
> run everything through the -O0 codegen when anything is 'optnone' -- but then,
> your existing 'optnone' attribute is in the exact same situation.)
>
> Nick
>
>>
>> About the DAE:
>> I agree that the DAE would end up removing unused arguments only in
>> trivial cases.
>> This may still be acceptable from a debugging perspective since it
>> wouldn't really negatively affect the user debugging experience (i.e. the
>> user simply will not be able to "see" dead argument).
>> However, if the plan is to achieve a behavior similar to -O0, then it may
>> still be better to not allow DAE to change optnone functions.
>>
>>>>
>>>>>> +    This attribute cannot be used together with the
>> ``alwaysinline``
>>>>>> +    attribute; this attribute is also incompatible
>>>>>> +    with the ``minsize`` attribute and the ``optsize`` attribute.
>>>>>> +
>>>>>> +    The inliner should never inline this function in any situation.
>>>>>> +    Only functions with the ``alwaysinline`` attribute are valid
>>>>>> +    candidates for inlining inside the body of this function.
>>>>>
>>>>> Ha, "alwaysinline" strikes again!  What happens when the unmovable
>>>>> "optnone" meets the irrestistable "alwaysinline"?  Maybe the compiler
>>>>> should just error out in this case: declare that this combination is
>>>>> invalid and have the verifier catch it.
>>>>
>>>> Yes, those attributes are incompatible and r189101 introduces rules in
>> the
>>>> Verifier to catch when attribute 'alwaysinline' is specified when
>>>> 'optnone' is also present.
>>>> If for example I define a function with both attributes optnone and
>>>> alwaysinline, then the verifier will be able to catch it and print out
>>>> that "Attributes 'alwaysinline and optnone' are incompatible!".
>>>
>>> I meant: what if the optnone function calls a function marked
>> alwaysinline.
>>> Inlining it into the optnone function changes the code of the optnone
>>> function, so is contrary to the principal that optnone function bodies
>> are
>>> just left alone.
>>
>> The idea is trying to get 'optnone' as close as possible to the -O0
>> behavior.
>> This is the main reason why I originally decided to allow the inlining of
>> alwaysinline
>> functions inside optnone functions.
>>
>> I think the documentation should be improved to emphasize that -O0
>> behavior.
>>
>> Andrea
>>
>> **********************************************************************
>> This email and any files transmitted with it are confidential and intended
>> solely for the use of the individual or entity to whom they are addressed.
>> If you have received this email in error please notify postmaster at scee.net
>> This footnote also confirms that this email message has been checked for
>> all known viruses.
>> Sony Computer Entertainment Europe Limited
>> Registered Office: 10 Great Marlborough Street, London W1F 7LP, United
>> Kingdom
>> Registered in England: 3277793
>> **********************************************************************
>>
>> P Please consider the environment before printing this e-mail
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>
>