• #ponce <aliloko gmail.com> Oct 05 2009
• Walter Bright <newshound1 digitalmars.com> Oct 05 2009
• BCS <none anon.com> Oct 05 2009
• Walter Bright <newshound1 digitalmars.com> Oct 05 2009
• Don <nospam nospam.com> Oct 05 2009
• Walter Bright <newshound1 digitalmars.com> Oct 06 2009
• Lutger <lutger.blijdestijn gmail.com> Oct 06 2009
• Walter Bright <newshound1 digitalmars.com> Oct 06 2009
• grauzone <none example.net> Oct 06 2009
• grauzone <none example.net> Oct 06 2009
• bearophile <bearophileHUGS lycos.com> Oct 06 2009
• Jarrett Billingsley <jarrett.billingsley gmail.com> Oct 06 2009
• "Denis Koroskin" <2korden gmail.com> Oct 06 2009

#ponce <aliloko gmail.com> writes:

 
 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.

Walter Bright <newshound1 digitalmars.com> writes:

#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.

BCS <none anon.com> writes:

Hello Walter,

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


 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? 

Walter Bright <newshound1 digitalmars.com> writes:

BCS wrote:
 Hello Walter,
 
 #ponce wrote:

 I think it's disabled in debug mode to keep the compilation time low.


 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.

Don <nospam nospam.com> writes:

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.


 source and assembler, making source debugging next to impossible.


 code and then do the optimizer backed test and only if no bugs jump out, 
 move the results into the object file?






 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.

Walter Bright <newshound1 digitalmars.com> writes:

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.

Lutger <lutger.blijdestijn gmail.com> writes:

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. 

Walter Bright <newshound1 digitalmars.com> writes:

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

grauzone <none example.net> writes:

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.


 make for pretty slow turnaround.


 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.


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

grauzone <none example.net> writes:

Denis Koroskin wrote:
 On Wed, 07 Oct 2009 00:54:22 +0400, grauzone <none example.net> wrote:
 
 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.


 would
 make for pretty slow turnaround.


 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.


        -debug -O


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


 No, -O means "optimize". It's just much easier to check code flow when 
 an executable is optimized, that's it.


And I thought it was a zero... never mind, then.

bearophile <bearophileHUGS lycos.com> writes:

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


On GCC if you want a safer compilation you add things like -Wall -Wextra, etc.

In D the default is better to be safe (just like you add -release to remove
some safeties), so with flow analysis activated. If someone needs a faster but
less safe compilation, then such person may add a flag to disable flow
analysis, like -noflow.

Bye,
bearophile

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

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 ar=








 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 woul=






 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=




 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:
 =A0 =A0 =A0 =A0-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.

"Denis Koroskin" <2korden gmail.com> writes:

On Wed, 07 Oct 2009 00:54:22 +0400, grauzone <none example.net> wrote:

 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.


 would
 make for pretty slow turnaround.


 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.


        -debug -O


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


No, -O means "optimize". It's just much easier to check code flow when an  
executable is optimized, that's it.