[LLVMbugs] [Bug 15887] New: Incorrect lexical scope information for local variable, with optimization

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=15887

            Bug ID: 15887
           Summary: Incorrect lexical scope information for local
                    variable, with optimization
           Product: new-bugs
           Version: 3.1
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: godepankaj at yahoo.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Summary:
Incorrect lexical scope information for local variable, with optimization

Steps to reproduce (just the options):
1. clang -O0 -g -c -emit-llvm x.c -S
2. opt x.s -mem2reg -loop-rotate -simplifycfg -o opt1
3. opt -O1  opt1 -o opt2
4. llc opt2 

Description:
I have used the patch on llvm3.1 file, llvm/lib/Transforms/Utils/Local.cpp  to
avoid multiple 'llvm.dbg.value' for a variable due to LowerDbgDeclare
optimization in 'instruction combining'.

For the code snippet below:

 62 int func(int dividend, int divisor, int *rem)
 63 {
 64   int d_sign = 0;
 65   int div_sign = 0;
 66   unsigned int d, r;
 67
 68   if (dividend < 0) { d_sign = 1; dividend = -dividend; };
 69   if (divisor < 0) { div_sign = 1; divisor = -divisor ; };
 70
 71   d = func1((unsigned int)dividend, (unsigned int)divisor, &r);
 72
 73   if (d_sign && div_sign) r = -r;
 74   else if (d_sign) { d = -d; r = -r; }
 75   else if (div_sign) { d = -d; };
 76
 77   if (rem) *rem = (signed int)r;
 78   return (signed int)d;
 79 }

The code generated code in .ll after 2nd optimization (opt tool execution)
looks like below.
@entry:
  call void @llvm.dbg.declare(metadata !{i32* %r}, metadata !68), !dbg !69

if.then6:                                         ; preds = %entry
  call void @llvm.dbg.value(metadata !{i32* %r}, i64 0, metadata !68), !dbg !80

if.then9:
  call void @llvm.dbg.value(metadata !{i32 %sub10}, i64 0, metadata !78), !dbg
!81
  call void @llvm.dbg.value(metadata !{i32* %r}, i64 0, metadata !68), !dbg !84
  %3 = load i32* %r, align 4, !dbg !84

if.then20:                                        ; preds = %if.end18
  call void @llvm.dbg.value(metadata !{i32* %r}, i64 0, metadata !68), !dbg !88
  %4 = load i32* %r, align 4, !dbg !88

!68 = metadata !{i32 786688, metadata !64, metadata !"r", metadata !6, i32 66,
metadata !9, i32 0, i32 0} ; [ DW_TAG_auto_variable ]

!64 = metadata !{i32 786443, metadata !13, i32 63, i32 1, metadata !6, i32 4} ;
[ DW_TAG_lexical_block ]

!72 = metadata !{i32 786443, metadata !64, i32 68, i32 21, metadata !6, i32 5}
; [ DW_TAG_lexical_block ]

!75 = metadata !{i32 786443, metadata !64, i32 69, i32 20, metadata !6, i32 6}
; [ DW_TAG_lexical_block ]

!82 = metadata !{i32 786443, metadata !64, i32 74, i32 20, metadata !6, i32 7}
; [ DW_TAG_lexical_block ]


Scopes identified are: 63-78, 68-68, 69-69, 74-74.


The point to note here is all these variable point to same metadata. In this
the 1st is 'llvm.dbg.declare' which ideally should be the real variable
declaration and the rest of the 'llvm.dbg.value' too point to same metadata,
which seems to be correct.  

But when I try to retrieve the variables for the function 'func' with below
code snippet,

I get 4 variables declared in the function using the llvm utility function
MachineModuleInfo::VariableDbgInfoMapTy &VMap =
MF->getMMI().getVariableDbgInfo();  . 
I iterate over these variables to find which scope they fit into. The problem
lies here.

    varlinenum  |  scope marked |  variable name
1.  66      |  63-78  |  r
2.  77      |  63-78  |  r
3.  74      |  74-74  |  r
4.  73      |  63-78  |  r

We can see here variable 'r' is identified to belong to same scope '63-78'. and
moreover all 'llvm.dbg.declare' when it is checked while debugging.

Reference llvm-dev post:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061703.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130501/014114a1/attachment.html>