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

[Michael Matz <matz at suse dot de>]

Hi,

On Mon, 9 Jul 2007, Alexandre Oliva wrote:

> > Thats true, but in today's world, we wouldn't coalesce those variables 
> > so its not an issue at the moment :-)
> 
> It is, because as I found out after my first patch, coalescing is not 
> the only issue.  The variable dies because bar is propagated over, and 
> then the assignment becomes dead and is deleted.  But we fail to emit 
> debug info even though the value is available.

We only fail to do that, because we lack the proper infrastructure on 
tree-ssa form, namely exactly the one we discuss about: attaching 
information to SSA names.  That infrastructure obviously also need to take 
care to update that side information on transformations affecting it.  
E.g. when propagating an SSA name holding a backing variable into uses 
without such, you can merge those associations.  If you propagate it into 
a complicated expression which isn't invertible, only then have you broken 
debug information.  But we already know that we simply can not express 
_all_ transformations the compiler does to code in debug info (not 
sensibly at least) without actively inhibiting some transformations.  We 
just should try harder to not disable too many of them.

> Here's a testcase that might look very familiar to you:  :-)
> 
> int i, j;
> int main(int argc, char *argv[]) {
>   int foo;
>   int bar = argc;
>   asm("");
>   foo = bar;
>   asm("");
>   bar++;
>   foo--;
>   asm("");
>   i = bar;
>   j = foo;
> }

With the proper infrastructure that is easy to handle.  More complicated 
cases arise in situations like this:

int array[100];
for (i = 0; i < 100; i++)
  a[i] = 42;

Let's say we're interested in where 'i' is.  Then we have a hard time when 
the compiler transforms this into:

int array[100];
char *ap = array, *ae = ap + 400;
for (; ap < ae; ap+=4)
  *(int*)ap = 42;

If you carefully do these transformation in SSA form you will see, that 
it's realtively clear where the interesting thing happens.  The original 
code will look something like:

i_2 = PHI<0,i_3>
i_3 = i_2 + 1
ap = &array[0] + i_2 * 4

and if you somehow propagate i_2 (backed by the user variable 'i') into 
that expression you have lost the place where 'i' might reside.  And 
rightly so, because that place indeed isn't needed in the transformed 
program.  If you hack hard enough you can nevertheless still determine the 
value of 'i' at all places, namely ((ap - &array[0]) / 4).  But also that 
needs the basic infrastructure of attaching debug information to SSA 
names.


Ciao,
Michael.