On Jul 22, 2008, at 10:33 PM, Chris Lattner wrote:> 1. I agree with Alexandre Oliva that the compiler should never "lie" > in debug info. If it has some information that is not accurate, it > should respond with "I don't know" instead of making a wrong guess. > This means that the debugger either says "your variable is certainly > here" or it says "I don't know", it never says "your variable might be > here".I agree.> 2. Based on #1, it is preferable for all optimizations to update debug > info. This improves the QoI of the debugging experience when the > optimizations are enabled. However, based on #1, if they can't or > haven't been updated yet, they should just discard it.What about possibility of skipping the optimization if it can not update debug info successfully ? When, I presented three levels, I did not focus on size of debug info. In fact, I focused on #1 feature you mention above. The levels, I presented intended to match choices the optimizer can take if debug information is available: choice 1: I know how to update debug info correctly. choice 2: I'm a vectorizer, I do not know how to let the debugger single step in a vectorized loop, but I know how to update other debug information in this function. choice 3: I do not know how to update debug info correctly. Should I do the optimization or skip ? Who wins, optimization level or debug- info level at the llvm-gcc command line ? - Devang
On Jul 23, 2008, at 10:44 AM, Devang Patel wrote:>> 2. Based on #1, it is preferable for all optimizations to update >> debug >> info. This improves the QoI of the debugging experience when the >> optimizations are enabled. However, based on #1, if they can't or >> haven't been updated yet, they should just discard it. > > What about possibility of skipping the optimization if it can not > update debug info successfully ?In my opinion, for llvm-gcc, this would be extremely bad. Enabling -g should not affect the machine code generated by the compiler. One reason why: compiler bugs do happen, and some users like enabling -g to try to understand what the optimizer is doing and find the bug. If enabling -g changes the code being generated, this can't work. -Chris
On Jul 23, 2008, at 10:52 AM, Chris Lattner wrote:> On Jul 23, 2008, at 10:44 AM, Devang Patel wrote: >>> 2. Based on #1, it is preferable for all optimizations to update >>> debug >>> info. This improves the QoI of the debugging experience when the >>> optimizations are enabled. However, based on #1, if they can't or >>> haven't been updated yet, they should just discard it. >> >> What about possibility of skipping the optimization if it can not >> update debug info successfully ? > > In my opinion, for llvm-gcc, this would be extremely bad. Enabling -g > should not affect the machine code generated by the compiler. One > reason why: compiler bugs do happen, and some users like enabling -g > to try to understand what the optimizer is doing and find the bug. If > enabling -g changes the code being generated, this can't work.They will use level 3 in that case. OK, I understand your point. I'll stop :) - Devang