[Mono-devel-list] SSA and try/catch/finally regions

Massimiliano Mantione massi at ximian.com
Mon Apr 4 07:43:44 EDT 2005

I'm going to do some work in the SSA construction code, so that
we will have proper SSA "versions" to represent field accesses.

While working on that code, I thought it would be nice to enable
SSA also when we currently cannot do it.

Now we disable SSA for the following reasons:
- Aliasing risks (the address of a local has been taken)
- try/catch/finally regions

The first issue is addressed by alias analysis, which (in a
limited form, but enough for this purpose) is already done.

The second one is related to the fact that try and catch/finally
blocks currently are not properly connected in the CFG.
But the real issue is not just how to connect the blocks, but how
to take into account the fact that when we reach a catch/finally
region the value of some variable is unpredictable.

I explain with a simple example:

                int v = 0;
		try {
			v = 1;
			DoSomething ();
			v = 2;
			DoSomeMore ();
			v = 3;
			DoEvenMore ();
		} finally {
	                Console.WriteLine (v);

Here, the value of 'v' in the finally BB depends from which of the
"Do..." methods (eventually) throws an exception.
So, simply connecting the try BB to the finally BB in the CFG (and,
by the way, also the finally BB to its "next" BB, which we now don't
do!) is not enough.

My idea is to use a sequence of OP_DUMMY_STORE instructions at the
beginning of catch/finally regions, one for each variable that is
assigned in the corresponding try region (and is actually used in
the catch/finally region, of course).

The complexity of doing this is low, and I think I can easily embed
this kind of scanning in the alias analysis pass (which already does
a full pass on the whole compiled method, looking for all load and
store instructions).
Maybe handling nested try regions will give me some trouble, but in
the end it should be easy...

In this way SSA would know that those variables have an unknown
value in those blocks.

Do you think this is a reasonable approach?


More information about the Mono-devel-list mailing list