Re: [rtlopt] Location list data

[Josef Zlomek <zlomj9am at artax dot karlin dot mff dot cuni dot cz>]

> I'm looking at the current location lists emitted by the rtlopt branch for a
> couple of simple testcases.  I've got GDB successfully using them, and it
> wasn't too painful to do; but there are some loose ends.  Here's one of
> them.  Consider this testcase:
> 
> int j = 2;
> 
> extern void baz (int *);
> void baz(int *bar)
> { 
>   ;
> }
> 
> int main()
> { 
>   int i = 1, k;
>   for (k = 0; k < 10; k++)
>     i = i * j;
>   baz (&i);
>   return i;
> }
> 
> 
> We've got a global variable 'j'.  On i386 with -O2, it gets loaded into a
> register.  The location list looks like this:
> 
>     00000013 00000021 00000027 (DW_OP_addr: 80493b8; )
>     00000013 00000027 0000002a (DW_OP_reg2; )
>     00000013 0000002a 00000032 (DW_OP_addr: 80493b8; )
>     00000013 00000032 0000003a (DW_OP_reg2; )
>     00000013 0000003a 00000040 (DW_OP_addr: 80493b8; )
> 
> i.e. during part of main it's in one place, during two small stretches it's
> in a register, then it's back in memory.  This is suboptimal for a couple of
> reasons.  We don't really need to say that it moves to the register, since
> it's never modified, but that's not a big deal.  What is a big deal is that
> the range is limited.  The code that goes along with it:
> 
>  8048331:       8b 15 b8 93 04 08       mov    0x80493b8,%edx
>  8048337:       83 e4 f0                and    $0xfffffff0,%esp
>  804833a:       8d b6 00 00 00 00       lea    0x0(%esi),%esi
>  8048340:       89 cb                   mov    %ecx,%ebx
>  8048342:       0f af da                imul   %edx,%ebx
>  8048345:       48                      dec    %eax
>  8048346:       89 d9                   mov    %ebx,%ecx
>  8048348:       79 f6                   jns    8048340 <main+0x20>
>  804834a:       8d 45 f8                lea    0xfffffff8(%ebp),%eax
>  804834d:       89 04 24                mov    %eax,(%esp,1)
>  8048350:       e8 bb ff ff ff          call   8048310 <baz>
> 
> So it "comes into existence" at the beginning of that move; then it "fades
> from existence" before the end of main.

Currently, the location list support on rtlopt branch handles only some
things:
it tracks variables which are used/set in a function, and function
parameters.
it remembers only the most recent location of the variable, so when the
most recent location gets destroyed (another value stored to register or so)
it does not know where the variable is.

Josef