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

[Kelly Leahy]

So does the CFG problems with catch blocks refer to
the fact that the CFG doesn't reflect all of the edges
from every place that can throw the exception to the
catch block?

I just spoke with a colleague of mine (one of the guys
that wrote a lot of those SSA papers) and he said he
thought there should be an edge for each place the
exception could be thrown and if there was, there is
no ambiguity as each of the edges contributes the
value of the var on its path to the PHI expression at
the catch node.

Kelly

--- Zoltan Varga <vargaz at gmail.com> wrote:
>                                       Hi,
> 
> On Apr 4, 2005 4:29 PM, Massimiliano Mantione
> <massi at ximian.com> wrote:
> > 
> > On Mon, 2005-04-04 at 14:28 +0200, Zoltan Varga
> wrote:
> > >   A simpler solution would be to mark those
> variables used in
> > > catch/finally blocks as volatile.
> > > This is already done.
> > 
> > Thanks for reminding me this issue (I really
> forgot it!).
> > 
> > It is a simpler approach, but it also prevents
> optimizations on
> > those variables in the *whole* method.
> > 
> 
> I'm not sure there is a need to optimize accesses to
> those variables. The bigger
> problem is that currently all variables which are
> used in bblocks reachable from
> catch blocks are also marked volatile, since the
> liveness info is not correctly
> computed for them because of the CFG problems with
> catch blocks.
> 
>                                     Zoltan
> 
> > A different approach would be to flag them as
> MONO_INST_INDIRECT
> > instead of MONO_INST_VOLATILE (to still prevent
> them from being
> > allocated in registers) and use the OP_DUMMY_STORE
> trick to mark
> > the places where they behave as "volatile", like I
> described.
> > 
> > I think this would still produce correct code, but
> enable more
> > optimizations opportunities.
> > So, my preference would go to the OP_DUMMY_STORE
> "trick", but
> > flagging catch/finally vars as MONO_INST_INDIRECT.
> > 
> > By the way, currently it seems to me that this
> flagging is done
> > in "mono_analyze_liveness", but what if we had
> some optimization
> > pass that runs *before* liveness has been computed
> but needs to
> > take this issue into account?
> > 
> > I know we have not this problem now, but the
> scenario is possible.
> > Suppose we go to semi-pruned SSA (which does not
> require liveness)
> > and also enable SSA in the presence of
> try/catch/finally clauses,
> > relying on the MONO_INST_VOLATILE flag to mark
> variables used in
> > catch/finally regions.
> > The flag will not be set, so the optimizations
> relying on it to
> > produce correct code would not work.
> > 
> > So, if we choose the MONO_INST_VOLATILE way,
> wouldn't it be better
> > to perform the flagging in a pass that we are
> *sure* will happen
> > before all the optimizations that need it?
> > Now we do one full code scan
> (handle_exception_clauses) just for
> > this purpose, but we do it inside
> mono_analyze_liveness...
> > 
> > Ciao,
> >   Massi
> > 
> >
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
>
http://lists.ximian.com/mailman/listinfo/mono-devel-list
>