On Tue, 2005-08-23 at 17:06 +0200, Bernd Schmidt wrote:
> Daniel Berlin wrote:
>
> > If you make them all defined, then it's going to be live where it wasn't
> > before, even though it's not really *used* over those paths.
>
> The idea is to put the initialization insns only on the paths where the
> register will be uninitialized.
Again, that will just make the register live over those paths, when it
wasn't before, which makes your information about liveness worse.
IE if you had
int foo(void)
{
int a;
if (blah)
a = 5;
<use a>
}
and you transform this to:
int foo(void)
{
int a;
if (blah)
a = 5;
else
a = 0;
<use a>
}
a is now considered live over both paths of the branch.whereas, with the
partial availability liveness, it will only be considered live over the
path it is actually initialized before use, which is the if branch.
Conservatively initialization will also lead to sets you can't
eliminate, and will generate real code, even if unreachable in practice.
Consider:
int argc;
int foo(void) {
int a;
while (argc--)
a = <value>
<use a>
}
Because you don't know the value of argc, dataflow will tell you it may
be uninitialized here.
To make it initialized, you'd have to conservatively transform this to:
int a;
a = 0;
while (argc--)
a = <value>
<use a>
Because you still don't know the value of argc, you won't be able to
remove the a = 0.
Besides not being able to remove them, you have to worry about placement
when it comes to loops.
Consider the simple nested loops
for i = 1 to 10
{
while (argv--)
{
a = <value>
}
}
<use a>
If you just "stupidly" place the initializations (IE don't do LCM like
dataflow to determine where they can go), you will transform this into:
for i = 1 to 10
{
a = 0;
while (argv--)
{
a = <value>
}
}
<use a>
You could avoid all but the "worse information" problem by tracking
which sets you added, and thus, know you can remove the sets if things
get bad, since they don't affect the original program.
However, this probably ends up being just as ugly as the partial
liveness stuff.
--Dan
