[PROPOSAL] per-function optimization level control

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] [PROPOSAL] per-function optimization level control

Eric Christopher
On Fri, Jun 14, 2013 at 10:36 AM, Xinliang David Li
<[hidden email]> wrote:

> On Fri, Jun 14, 2013 at 4:06 AM,  <[hidden email]> 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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] [PROPOSAL] per-function optimization level control

Xinliang David Li-2
On Fri, Jun 14, 2013 at 11:36 AM, Eric Christopher <[hidden email]> wrote:

> On Fri, Jun 14, 2013 at 10:36 AM, Xinliang David Li
> <[hidden email]> wrote:
>> On Fri, Jun 14, 2013 at 4:06 AM,  <[hidden email]> 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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] [PROPOSAL] per-function optimization level control

Eric Christopher
On Fri, Jun 14, 2013 at 11:52 AM, Xinliang David Li
<[hidden email]> wrote:

> On Fri, Jun 14, 2013 at 11:36 AM, Eric Christopher <[hidden email]> wrote:
>> On Fri, Jun 14, 2013 at 10:36 AM, Xinliang David Li
>> <[hidden email]> wrote:
>>> On Fri, Jun 14, 2013 at 4:06 AM,  <[hidden email]> 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.
>

Totally agree. I've done exactly that myself. :)

and the first part is exactly why I was resistant to the idea in the
first place - besides my ivory tower idea that the compiler should
handle everything perfectly ;)

-eric
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
12