Proposal: Debug information improvement - keep the line number with optimizations

Hi Patel,

Here is second part of my reply.

2. Proposed Work Plan
> This section defines a proposed work plan to accomplish the
> requirements that we desires. The work plan is broken into several
> distinct phases that follow a logical progression of modifications
> to the LLVM software.
>
> 2.1 Phase 1: Establish the testing system
> One of the most useful things to get started is to have some way to
> determine whether codegen is being impacted by debug info. It is
> important to be able to tell when this happens so that we can track
> down these places and fix them.
>
> 2.1.1 Pass Scanning Script
> Following the way proposed by Chris, it is good to have a script to
> scan the standard LLVM transform pass list. We can get the standard
> compile optimization pass list by:
  
You can use http://llvm.org/docs/SourceLevelDebugging.html#debugopt as
a starting point here.
  
Ok.

>
> $ opt -std-compile-opts -debug-pass=Arguments foo.bc > /dev/
> null

...
...

2.2 Phase 2: New Pass to Strip Debug Information
> LLVM already has a transform pass "-strip-debug", it removes all the
> debug information. But for the first half of this project, we want
> to just keep the line number information (stop point) in the
> optimized code. So we need a new transform pass to just removes the
> variable declaration information. Pass "-strip-debug" also doesn't
> cleanup the dead variable and function calling for debug
> information, it thinks other pass like "-dce" or "-globaldce" can
> handle this. But as we are also going to update those passes, we
> can't use them in the verification flow, otherwise, it may output
> incorrect check results.
>
> The new pass "-strip-debug-pro" should have the following functions:
> 1. Just remove the variable declaration information and
> clean up the dead debug information.
>
> 2. Remove all the debug information and clean up
>
> 3.2.1 Work Plan
> 1. Take a reference to transform pass StripSymbol.cpp
> 2. Based on the StripSymbol.cpp, add an option to it to just
> remove debug information, like "-rm-debug"
  
That's what -strip-debug is doing.

> 3. Add an option to just remove the variable declaration
> information, like "?rm-debug=2"
    
Why not -strip-debug=2 if you want a way to remove variable
declarations ..?
  

Agree.

  

> 4. Add a procedure to clean up the dead variables and
> function calls for debug purpose.
>
> 2.3 Phase 3: Extend llvm-gcc
> Once we have a way to verify what is happening, I propose that we
> aim for an intermediate point: instead of having -O disable all
> debug info, we should make it disable just variable information, but
> keep emitting line number info. This would allow stepping through
> the program, getting stack traces, use performance tools like shark,
> etc.
>
> We need the front-end llvm-gcc to have a mode that causes it to emit
> line number info but not
> variable info, we can go through the process above to identify
> passes that change behavior when line number intrinsics are in the
> code.
>
> 1.3.1 Work Plan
> 1. First locate the file position that llvm-gcc handle the
> parameter options.
> 2. Add a new option to control the llvm-gcc to emit
> specified debug information: like ?g1. ?g1 to only emit line number
    
> 3. Building the new llvm-gcc
> 4. Testing through llvm/test, llvm-test
>
> 2.4 Phase 4: Update Transform Passes for Line Number Info.
> When the front-end has a mode that causes it to emit line number
> info but not variable info, we can go through the process above to
> identify passes that change behavior when line number intrinsics are
> in the code.
    
I think, the optimizer is not changing behavior when dbg info is
present. Try running dbgopt tests.

> Obvious cases are things like loop unroll and inlining: they
> 'measure' the size of some code to determine whether to unroll it or
> not. This means that it should be enhanced to ignore debug
> intrinsics for the sake of code size estimation.
    
The loop unrolling pass already ignores the debug info! See
LoopUnroll.cpp::ApproximateLoopSize()
  

ok, I see.