[Mono-devel-list] A clarification on the purpose of alias analysis.

[Massimiliano Mantione]

On Thu, 2005-02-24 at 13:46, Willibald Krenn wrote:
> Is there a point in doing 'half' 2: I mean do only locals, but also 
> consider instance fields?

If the "instance" that has a field is a local struct (a valuetype)
this is almost equivalent to [1].
In practice, this is [1] if you do scalar replacement or something
similar, I mean if you track the value of each field separately.
In this case, your 'half 2' is just as complex as [1].

If, on the other hand, the instance that has a field is not a
valuetype, besides the "scalar replacement" thing all the issues
related to [2] apply, because the value is allocated outside the
method... potentially anything external could change its value
at any time.

The other optimization that is related to these cases is detecting
those objects that are created in the method but never passed to
any call (or returned), and never stored anywhere outside locals.
Those objects would be "like valuetypes" (it is like if they were
local to the method), and so for them 'half 2' would be like [1].
In fact, those objects could in principle be allocated on the stack
and nobody would care (if finalizers were run anyway).

> I'm still a little bit disappointed that it's impossible to do
> abcremoval on cases where the var is not local.. (But I
> guess this has little to do with alias analysis, correct?)

Yes, and no.
It has to do with the possibility of tracking values accurately.

We can do abcremoval if we can statically determine the value of
things (and put the variables holding those values in SSA form).
So, with something like scalar replacement in place, we would
track the value of individual fields, and therefore abcrem would
work on fields as well.
Without that, even if we enable SSA also with aliases around, each
field has an unknown value, so abcrem cannot do its job.

Hope this is clear...

Ciao,
  Massi