Open Quuxplusone opened 11 years ago
Bugzilla Link | PR15887 |
Status | NEW |
Importance | P normal |
Reported by | pankaj (godepankaj@yahoo.com) |
Reported on | 2013-05-01 09:08:27 -0700 |
Last modified on | 2013-05-17 01:09:41 -0700 |
Version | 3.1 |
Hardware | PC Linux |
CC | llvm-bugs@lists.llvm.org, rafael@espindo.la |
Fixed by commit(s) | |
Attachments | |
Blocks | |
Blocked by | |
See also |
As Adrian said, "we attach the debug location of the load/store instruction to
the dbg.value (and thus it gets the enclosing scope of the use as scope), but
we could attach the debug location of the original dbg.declare intrinsic to the
dbg.value", I too feel, it should be fine to attach debug location of original
dbg.declare intrinsic to dbg.value.
I get this problem because of a stack based architecture we have, where we
expect local variables to be stored on stack. The scenario which I had
described, for the optimization, it wouldn't have been a problem if we had the
facility of making the same variables as 'register variables'. This is a
architecture constraint though.
Even with this constraint, user checking for 'debug information with optimized
code', would like this optimized variable still to point to original
dbg.declare.
I also observed that after 'inilinng optimization', the debug location
information is not updated for the inlined instructions. A case.
func()
{
struct some some1;
func1( &some1);
}
func1(struct some *this)
{
return func2( this); //just this call
}
func2( struct some *this)
{
//some code which can be inlined
}
For the optimized code, one expects the debug information reflects optimization.