This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [rtlopt] Location list data
On Mon, Mar 10, 2003 at 05:35:16PM +0100, Josef Zlomek wrote:
> > 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.
In that case should we not even bother emitting a list for global
variables? Having them disappear outside the function is pretty
unfriendly.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer