> AFAIU, it's not OK for -g to affect code generation. I agree with the > rest of your plan.That's correct, -g must not affect code generation. This is a fundamental mantra among debug-info people.> > > On Wed, Nov 27, 2013 at 2:16 PM, Renato Golin <renato.golin at linaro.org> > wrote: > > On 27 November 2013 08:43, Evgeniy Stepanov > <eugeni.stepanov at gmail.com> > > wrote: > >> > >> Also note that tail merging of calls happens in CodeGen, not in > >> SimplifyCFG. > > > > > > Hi Evgenly, > > > > What we need is the general information that we want to avoid too much > code > > motion, from choosing the passes, to choosing steps on the passes, to > > lowering code differently. > > > > On the front-end layer, It's as simple as dealing -O levels. > > > > On the middle-end, we could have front-ends to set a flag "debug- > illusion" > > on each individual pass, so that they could use this information to > take > > decisions locally, independent of the -O level (which they don't have > access > > to). This flag should only be set if the user requests -g and the > > optimization level is not greater than 1.Intuitively I'd expect that the set of passes to be run would vary with opt level, and much less often would a pass want to vary its behavior according to opt level. But "much less often" isn't "never" and so it seems very weird that a pass wouldn't know the opt level. Some indication of "be sanitizer/debugger friendly" that can guide pass internal behavior seems like a good plan. I had this in a previous compiler I worked on, and it was extremely helpful in producing code that was easy to debug. --paulr> > > > On the back-end, I think the only place global enough that the front- > end has > > access to is the Target description, which could have a similar flag > to > > avoid folding too much during codegen. > > > > cheers, > > --renato > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On 27 November 2013 19:36, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote:> That's correct, -g must not affect code generation. This is a > fundamental mantra among debug-info people.I think you both got me on the wrong side, though I admit my email wasn't clear. I didn't mean to suggest changing codegen for debug purposes only, but on -O1 to be less aggressive on some parts than it is today. Some flag saying "optimize-for-debug". It's not easy to know what kind of optimization you can do that won't change how the program runs, and thus changing how the program breaks, so maybe the -g special flag was a bad idea to begin with. But the need to make -O1 be debuggable could very well be the just the thing I needed to give names to the optimization options. Earlier this year I proposed we have names, rather than numbers, that would represent our optimization levels: 0 = Debug 1 = FastDebug 2 = Speed 3 = Aggressive S = Space Z = SpaceAggressive I'm assuming there is little value in -O1 than just a faster debug experience, so why not make it take decisions on the debug illusion as well? Ie. ignore my -g/-O1 dependency I proposed.> Intuitively I'd expect that the set of passes to be run would vary with > opt level, and much less often would a pass want to vary its behavior > according to opt level. But "much less often" isn't "never" and so it > seems very weird that a pass wouldn't know the opt level.As far as I know (and I may be wrong), the passes only have access to things like "optimize-for-space/speed". Because optimization levels don't mean anything concrete, it'd be a bit silly to have an "if (opt == 3) do this" in a pass.> Some indication of "be sanitizer/debugger friendly" that can guide > pass internal behavior seems like a good plan. I had this in a previous > compiler I worked on, and it was extremely helpful in producing code > that was easy to debug.That's the plan. If the optimization levels (at least in LLVM) have names, we can easily make -OFastDebug and -ODebug have the same "debug" flag set, and so on. enum OptLevel { Debug = 1, // Debug Illusion Speed = 2, // Performance Space = 4, // Size Aggressive = 8, } -O0 = Debug -O1 = Debug+Aggressive -O2 = Speed -O3 = Speed+Aggressive -Os = Space -Oz = Space+Aggressive Then passes only need to know which flags are set... In our specific case, not running SimplifyCFG and friends would only need to know "if (OptLevel.isSpeed()) simplify();". At least the code would make more sense to the reader... cheers, --renato
> -----Original Message----- > From: Renato Golin [mailto:renato.golin at linaro.org] > Sent: Wednesday, November 27, 2013 12:02 PM > To: Robinson, Paul > Cc: Evgeniy Stepanov; LLVM Developers Mailing List > Subject: Re: [LLVMdev] Disabling certain optimizations at -O1? > > On 27 November 2013 19:36, Robinson, Paul > <Paul_Robinson at playstation.sony.com> wrote: > > That's correct, -g must not affect code generation. This is a > > fundamental mantra among debug-info people. > > I think you both got me on the wrong side, though I admit my email > wasn't clear. I didn't mean to suggest changing codegen for debug > purposes only, but on -O1 to be less aggressive on some parts than it > is today. Some flag saying "optimize-for-debug".Ah, okay. Sounds good.> > It's not easy to know what kind of optimization you can do that won't > change how the program runs, and thus changing how the program breaks,Any optimization ought to preserve the overall behavior of the program. The point where optimizations interfere with debugging is when they take a simple mapping of instructions/values back to source code, and make that mapping more complicated. When is it "too" complicated? That's not a completely heuristic question, although it is too large a question to get into here. In my experience, to a first approximation, anything that changes the CFG or that reorders generated code beyond source statement boundaries is likely to make things more difficult for the debugger.> so maybe the -g special flag was a bad idea to begin with. But the > need to make -O1 be debuggable could very well be the just the thing I > needed to give names to the optimization options. > > Earlier this year I proposed we have names, rather than numbers, that > would represent our optimization levels: > > 0 = Debug > 1 = FastDebug > 2 = Speed > 3 = Aggressive > S = Space > Z = SpaceAggressive > > I'm assuming there is little value in -O1 than just a faster debug > experience, so why not make it take decisions on the debug illusion as > well? Ie. ignore my -g/-O1 dependency I proposed.Okay. I worked on compilers where -O1 was the default, actually, and it was "generally fast enough" but still very easy to produce very good debug info.> > > > Intuitively I'd expect that the set of passes to be run would vary > with > > opt level, and much less often would a pass want to vary its behavior > > according to opt level. But "much less often" isn't "never" and so it > > seems very weird that a pass wouldn't know the opt level. > > As far as I know (and I may be wrong), the passes only have access to > things like "optimize-for-space/speed". > > Because optimization levels don't mean anything concrete, it'd be a > bit silly to have an "if (opt == 3) do this" in a pass.Hm okay, I could see that passes would rather have some kind of more semantically significant criteria.> > > > Some indication of "be sanitizer/debugger friendly" that can guide > > pass internal behavior seems like a good plan. I had this in a > previous > > compiler I worked on, and it was extremely helpful in producing code > > that was easy to debug. > > That's the plan. > > If the optimization levels (at least in LLVM) have names, we can > easily make -OFastDebug and -ODebug have the same "debug" flag set, > and so on. > > enum OptLevel { > Debug = 1, // Debug Illusion > Speed = 2, // Performance > Space = 4, // Size > Aggressive = 8, > } > > -O0 = Debug > -O1 = Debug+Aggressive > -O2 = Speed > -O3 = Speed+Aggressive > -Os = Space > -Oz = Space+Aggressive > > Then passes only need to know which flags are set...I see what you're driving at although I'd quibble about two things. - "Debug" is kind of overloaded, maybe "Simple" would express the right semantic without being so ambiguous (avoid the -g thing!). - I wonder whether Simple/Speed/Space are better modeled as a single three-way setting and not as flags. Is it sensible to have more than one of those three on at the same time? I wouldn't think so... --paulr> > In our specific case, not running SimplifyCFG and friends would only > need to know "if (OptLevel.isSpeed()) simplify();". At least the code > would make more sense to the reader... > > cheers, > --renato