llvm dev - Jun 2013 - [LLVMdev] [cfe-dev] [PROPOSAL] per-function optimization level control

On Fri, Jun 14, 2013 at 4:06 AM,  <Andrea_DiBiagio at sn.scee.net>
wrote:
> Hi David,
>
>> Regarding Andrea's proposal -- the new #pragma can be useful (in
rare
>> cases when there is a compiler bug), the intended use cases are
>> questionable:
>> 1) it should not be used as a mechanism to triage compiler bugs -- the
>> compiler backend should have mechanism to allow any pass to be
>> disabled for any (range of) function(s) via command line options so
>> that it can be automated -- you should not expect doing this via
>> source modification
>> 2) Improve debuggability of optimized code. GCC has -Og option that
>> can be used to generate well optimized code with good debuggability.
>> 3) there is a much bigger issue if the customer needs to resort to
>> this pragmas frequently to hide optimizer bugs.
>
> Just to clarify, although in our opinion the ability to workaround
> optimization
> bugs is a useful side effect of this proposal, we don't consider it the
> main
> use case.
> That's probably my fault, I should have put more emphasis on the main
use
> case:
>
> "The main motivation of our customers is to be able to selectively
disable
> optimizations when debugging one function in a compilation unit, in the
> case
> where compiling the whole unit at -O0 would make the program run too
> slowly."
>
> In general, it is something that should help improve the debugging
> experience when customers have to debug specific portions of their code
> without sacrificing any of their overall runtime performances.
> As a side note, using GCC is not a option for us.
>
To be clear, I am not advocating GCC at all here. Just pointing out
there is room for improvement for DOC so that user does not need to
resort to these workarounds. I know Eric Christopher  is working very
hard to make this happen for LLVM :)

thanks,

David

> **********************************************************************
> 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

On Fri, Jun 14, 2013 at 10:36 AM, Xinliang David Li
<xinliangli at gmail.com> wrote:
> On Fri, Jun 14, 2013 at 4:06 AM,  <Andrea_DiBiagio at sn.scee.net>
wrote:
>> Hi David,
>>
>>> Regarding Andrea's proposal -- the new #pragma can be useful
(in rare
>>> cases when there is a compiler bug), the intended use cases are
>>> questionable:
>>> 1) it should not be used as a mechanism to triage compiler bugs --
the
>>> compiler backend should have mechanism to allow any pass to be
>>> disabled for any (range of) function(s) via command line options so
>>> that it can be automated -- you should not expect doing this via
>>> source modification
>>> 2) Improve debuggability of optimized code. GCC has -Og option that
>>> can be used to generate well optimized code with good
debuggability.
>>> 3) there is a much bigger issue if the customer needs to resort to
>>> this pragmas frequently to hide optimizer bugs.
>>
>> Just to clarify, although in our opinion the ability to workaround
>> optimization
>> bugs is a useful side effect of this proposal, we don't consider it
the
>> main
>> use case.
>> That's probably my fault, I should have put more emphasis on the
main use
>> case:
>>
>> "The main motivation of our customers is to be able to selectively
disable
>> optimizations when debugging one function in a compilation unit, in the
>> case
>> where compiling the whole unit at -O0 would make the program run too
>> slowly."
>>
>> In general, it is something that should help improve the debugging
>> experience when customers have to debug specific portions of their code
>> without sacrificing any of their overall runtime performances.
>> As a side note, using GCC is not a option for us.
>>
>
> To be clear, I am not advocating GCC at all here. Just pointing out
> there is room for improvement for DOC so that user does not need to
> resort to these workarounds. I know Eric Christopher  is working very
> hard to make this happen for LLVM :)
>
Assuredly. FWIW I like Andrea's new proposal as a good first step. I
definitely acknowledge the usefulness of having almost all of the app
running at full speed and only having a small function at O0 to get a
better debugging experience. The full set of passes enabled this way?
Not quite convinced yet :)

-eric

On Fri, Jun 14, 2013 at 11:36 AM, Eric Christopher <echristo at gmail.com>
wrote:
> On Fri, Jun 14, 2013 at 10:36 AM, Xinliang David Li
> <xinliangli at gmail.com> wrote:
>> On Fri, Jun 14, 2013 at 4:06 AM,  <Andrea_DiBiagio at
sn.scee.net> wrote:
>>> Hi David,
>>>
>>>> Regarding Andrea's proposal -- the new #pragma can be
useful (in rare
>>>> cases when there is a compiler bug), the intended use cases are
>>>> questionable:
>>>> 1) it should not be used as a mechanism to triage compiler bugs
-- the
>>>> compiler backend should have mechanism to allow any pass to be
>>>> disabled for any (range of) function(s) via command line
options so
>>>> that it can be automated -- you should not expect doing this
via
>>>> source modification
>>>> 2) Improve debuggability of optimized code. GCC has -Og option
that
>>>> can be used to generate well optimized code with good
debuggability.
>>>> 3) there is a much bigger issue if the customer needs to resort
to
>>>> this pragmas frequently to hide optimizer bugs.
>>>
>>> Just to clarify, although in our opinion the ability to workaround
>>> optimization
>>> bugs is a useful side effect of this proposal, we don't
consider it the
>>> main
>>> use case.
>>> That's probably my fault, I should have put more emphasis on
the main use
>>> case:
>>>
>>> "The main motivation of our customers is to be able to
selectively disable
>>> optimizations when debugging one function in a compilation unit, in
the
>>> case
>>> where compiling the whole unit at -O0 would make the program run
too
>>> slowly."
>>>
>>> In general, it is something that should help improve the debugging
>>> experience when customers have to debug specific portions of their
code
>>> without sacrificing any of their overall runtime performances.
>>> As a side note, using GCC is not a option for us.
>>>
>>
>> To be clear, I am not advocating GCC at all here. Just pointing out
>> there is room for improvement for DOC so that user does not need to
>> resort to these workarounds. I know Eric Christopher  is working very
>> hard to make this happen for LLVM :)
>>
>
> Assuredly. FWIW I like Andrea's new proposal as a good first step. I
> definitely acknowledge the usefulness of having almost all of the app
> running at full speed and only having a small function at O0 to get a
> better debugging experience. The full set of passes enabled this way?
> Not quite convinced yet :)
The problem with this approach (selective O0) is that you can only
look at the function itself with full debug. Very often you will need
to examine the context of the call. Besides what if the function is
the hottest one in the program?  Having said that, I did this a lot
myself when debugging a program -- just recompile the module i care
about with -O0 -g and relink.

thanks,

David
>
> -eric