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. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131127/89668558/attachment.html>
AFAIU, it's not OK for -g to affect code generation. I agree with the rest of your plan. 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. > > 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
> 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