Re: [tree-ssa] Java: Decls that alias?

[Jeff Sturm <jsturm at one-point dot com>]

On Tue, 16 Sep 2003, Andrew Haley wrote:
>  > Andrew, I'm not sure I really understand the problem.  Is this somehow
>  > related to the bytecode failures currently on tree-ssa?
>
> I think so.
>
> Imagine you have "Slot 4", and this contains a jint.
>
> At one point in the program, "Slot 4" might have debug info with a
> variable name "bar".  At another point, "Slot 4" might have debug info
> with a variable name "foo".  But semantically they are the same
> variable -- an assignment to "Slot 4" can refer either to "foo" or
> "bar".  So, we need to treat "foo" and "bar" as two names of a single
> variable.

I see.  So this only matters if you have debug info and wish to generate
debug info in the object file?  Otherwise you can create one decl for each
slot (or pair of slots, for a long/double) and be done with it.

> Also, at some point in the program there might be no debug info at all
> for "Slot 4", yet it's still legal to refer to that slot.  A write to
> "Slot 4" might be read later as "foo" or "bar".

I'd guess this is legal in the sense that the bytecode verifier ignores
LocalVariableTable attributes?  It doesn't sound like reasonable behavior
for any compiler, legal or not.

> We handle this in the current byte compiler by sharing RTL between all
> the decls that correspond to "Slot 4".

I'd think it would be cleaner to keep one decl per slot.  But then I don't
know how you'd get the debug info right, unless you place all the aliasing
decls in an anonymous union.

I wonder what Fortran will do for the EQUIVALENCE keyword.  The g77 docs
seem to say it doesn't emit debug info at all for these.

Do you think users really care much about symbolic debugging when
compiling class files?  I presume they'd only need it when they don't have
source code, in which case the symbolic debug info is only marginally
useful anyhow.

Jeff