[llvm] r189101 - Add function attribute 'optnone'.
silvas at purdue.edu
Thu Sep 19 07:23:34 PDT 2013
On Wed, Sep 18, 2013 at 1:05 PM, Duncan Sands <duncan.sands at gmail.com>wrote:
> Hi Andrea,
> Attribute optnone was originally intended to be used mainly for debugging
>>> 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
>>> to a function would allow the user to debug that function as if it were
>>> unoptimized build but having the rest of the program fully optimized.
>>> this use case in mind, I originally decided to make the 'optnone'
>>> 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
> levels become an attribute attached to functions, then we could have a
> -Og attribute and teach the optimizers not to do optimizations that
> play badly with debug info. But for the moment -O1 is the closest thing
> we have
> to -Og.
I haven't looked in depth at -Og, but at least for -O1, it's not really
viable to compile these games with -O1. Remember that these games push up
hard against a frame time limit, so in general anything that globally
decreases performance will cause frames to be missed. Anecdotally from my
work this Summer, compiling with -O1 (vs the usual of -O2/-O3) results in
the game essentially becoming unplayable (and with -O0 globally it's even
worse: the game doesn't just run slow, it' doesn't run *at all* (it can't
meet deadlines necessary to even put an image on the screen!)).
-- Sean Silva
> 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
> 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
>> 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
>> 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
>> the other ones. Or you could make a small extension to add a
>> 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.
>> a functions's blocks into a parentless function will leave a declaration
>> place in the module at the same pointer address. Then you put it back
>> 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
>> run everything through the -O0 codegen when anything is 'optnone' -- but
>> your existing 'optnone' attribute is in the exact same situation.)
>>> 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
>>>> + 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
>>>> 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
>>>> Inlining it into the optnone function changes the code of the optnone
>>>> function, so is contrary to the principal that optnone function bodies
>>>> just left alone.
>>> The idea is trying to get 'optnone' as close as possible to the -O0
>>> This is the main reason why I originally decided to allow the inlining of
>>> functions inside optnone functions.
>>> I think the documentation should be improved to emphasize that -O0
>>> This email and any files transmitted with it are confidential and
>>> solely for the use of the individual or entity to whom they are
>>> 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
>>> Registered in England: 3277793
>>> P Please consider the environment before printing this e-mail
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits