> 
> Somewhere in the huge thread(s) on the topic Walter mentioned the optimizer does (some of) the required flow analysis, so presumably it needs to run in order for this to work.

I think it's disabled in debug mode to keep the compilation time low.
I guess it's more expensive CPU-wise than escape analysis which is done in both modes.
So it seems the right thing to do for me.

#ponce wrote:
> I think it's disabled in debug mode to keep the compilation time low. 

That, and the optimizer tends to scramble the relationship between source and assembler, making source debugging next to impossible.

> I guess it's more expensive CPU-wise than escape analysis which is done in both modes.
> So it seems the right thing to do for me.

Hello Walter,

> #ponce wrote:
> 
>> I think it's disabled in debug mode to keep the compilation time low.
>> 
> That, and the optimizer tends to scramble the relationship between
> source and assembler, making source debugging next to impossible.
> 

How hard would it be to have the code generate run on the unoptimized code and then do the optimizer backed test and only if no bugs jump out, move the results into the object file? 

BCS wrote:
> Hello Walter,
> 
>> #ponce wrote:
>>
>>> I think it's disabled in debug mode to keep the compilation time low.
>>>
>> That, and the optimizer tends to scramble the relationship between
>> source and assembler, making source debugging next to impossible.
>>
> 
> How hard would it be to have the code generate run on the unoptimized code and then do the optimizer backed test and only if no bugs jump out, move the results into the object file?
> 

It seems even easier to just compile with -0.

Nick Sabalausky wrote:
> "Nick Sabalausky" <a@a.a> wrote in message news:hadst9$581$1@digitalmars.com...
>> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:hadqcs$30n8$2@digitalmars.com...
>>> BCS wrote:
>>>> Hello Walter,
>>>>
>>>>> #ponce wrote:
>>>>>
>>>>>> I think it's disabled in debug mode to keep the compilation time low.
>>>>>>
>>>>> That, and the optimizer tends to scramble the relationship between
>>>>> source and assembler, making source debugging next to impossible.
>>>>>
>>>> How hard would it be to have the code generate run on the unoptimized code and then do the optimizer backed test and only if no bugs jump out, move the results into the object file?
>>>>
>>> It seems even easier to just compile with -0.
>> It isn't. *Very* typical workflow:
>>
> [stuff]
>> None of those are particularly good options, and I don't see any other possibilities.
>>
> 
> ...Plus it's just plain unintuitive.

It's pretty standard, though. For example, there are some bugs which Visual C++ detects only when the optimiser is on. From memory, they are all flow-related. The MS docs recommend compiling a release build occasionally to catch them.

Don wrote:
> It's pretty standard, though. For example, there are some bugs which Visual C++ detects only when the optimiser is on. From memory, they are all flow-related. The MS docs recommend compiling a release build occasionally to catch them.


The flow analysis could be run on every compile by default, but it would make for pretty slow turnaround.

Walter Bright wrote:

> Don wrote:
>> It's pretty standard, though. For example, there are some bugs which Visual C++ detects only when the optimiser is on. From memory, they are all flow-related. The MS docs recommend compiling a release build occasionally to catch them.
> 
> 
> The flow analysis could be run on every compile by default, but it would make for pretty slow turnaround.

Is it possible / reasonably to run flow analysis but still have a build that can be properly debugged? If yes, wouldn't it be nice to have it as a separate compiler option? Some people with build slaves, fast cpu's or smallish projects won't care that much for the performance.

Lutger wrote:
> Walter Bright wrote:
> 
>> Don wrote:
>>> It's pretty standard, though. For example, there are some bugs which
>>> Visual C++ detects only when the optimiser is on. From memory, they are
>>> all flow-related. The MS docs recommend compiling a release build
>>> occasionally to catch them.
>>
>> The flow analysis could be run on every compile by default, but it would
>> make for pretty slow turnaround.
> 
> Is it possible / reasonably to run flow analysis but still have a build that can be properly debugged? If yes, wouldn't it be nice to have it as a separate compiler option? Some people with build slaves, fast cpu's or smallish projects won't care that much for the performance. 

Just compile with:
	-debug -O

On Tue, Oct 6, 2009 at 3:08 PM, Walter Bright <newshound1@digitalmars.com> wrote:
> Lutger wrote:
>>
>> Walter Bright wrote:
>>
>>> Don wrote:
>>>>
>>>> It's pretty standard, though. For example, there are some bugs which Visual C++ detects only when the optimiser is on. From memory, they are all flow-related. The MS docs recommend compiling a release build occasionally to catch them.
>>>
>>> The flow analysis could be run on every compile by default, but it would make for pretty slow turnaround.
>>
>> Is it possible / reasonably to run flow analysis but still have a build that can be properly debugged? If yes, wouldn't it be nice to have it as a separate compiler option? Some people with build slaves, fast cpu's or smallish projects won't care that much for the performance.
>
> Just compile with:
>        -debug -O

You don't seem to be grasping the issue here. It's not using -O with -debug that's the problem, it's using it with -g. You can't reasonably expect someone to put an optimized executable through a debugger.

Jarrett Billingsley wrote:
> On Tue, Oct 6, 2009 at 3:08 PM, Walter Bright
> <newshound1@digitalmars.com> wrote:
>> Lutger wrote:
>>> Walter Bright wrote:
>>>
>>>> Don wrote:
>>>>> It's pretty standard, though. For example, there are some bugs which
>>>>> Visual C++ detects only when the optimiser is on. From memory, they are
>>>>> all flow-related. The MS docs recommend compiling a release build
>>>>> occasionally to catch them.
>>>> The flow analysis could be run on every compile by default, but it would
>>>> make for pretty slow turnaround.
>>> Is it possible / reasonably to run flow analysis but still have a build
>>> that can be properly debugged? If yes, wouldn't it be nice to have it as a
>>> separate compiler option? Some people with build slaves, fast cpu's or
>>> smallish projects won't care that much for the performance.
>> Just compile with:
>>        -debug -O
> 
> You don't seem to be grasping the issue here. It's not using -O with
> -debug that's the problem, it's using it with -g. You can't reasonably
> expect someone to put an optimized executable through a debugger.

As I understand, -0 just enables flow analysis (which is slow and thus shouldn't be run normally), not full optimization.