This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PR 23551: why should we coalesce inlined variables?


On Jul  9, 2007, "Daniel Berlin" <dberlin@dberlin.org> wrote:

>> Attaching the variables is just not enough.  You have to attach the
>> assignment points as well.  And I haven't see you address that at all,
>> even though it is a necessary part of the infrastructure.

> Each ssa name has a single definition statement.

Yes, but the point is that, after copy propagation, the same
assignment may be associated with multiple variables, and for all but
one of them, the assignment point would provide us with the *wrong*
range starting point.

This is one of the things that needs fixing.

0: foo = f();
...
1: bar = foo;
...
2: bar = f();

optimizes to:

0: foo_1 = f(); /* foo, bar */
...
1:
...
2: bar_2 = f(); /* bar */

How do I generate debug info for bar such that the range in which it's
associated with foo_1 is 1..2 rather than 0..2?


I've already suggested adding annotations that remain after
assignments are optimized away, such that we initially have:

0: /* foo = */ foo_1 = f ();
...
1: /* bar = */ bar_1 = foo_1;
...
2: /* bar = */ bar_2 = f ();

but then, after optimization, we still have:

0: /* foo = */ foo_1 = f ();
...
1: /* bar = foo_1; */
...
2: /* bar = */ bar_2 = f ();

See, now I can emit correct debug info for bar.

Is there any reason not to do it this way?

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]