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

[Zoltan Varga]

                                       Hi,

  I don't know much about the CFG stuff, but given the following code:

 int i = 0;

try {
}
catch {
...
}

i = i + 1

with the current JIT, the liveness range of 'i' does not include the
catch block, so if
i is not made volatile, the JIT might allocate 'i' and a variable used
in the catch block to
the same global register, screwing things up.

                     Zoltan

On Apr 4, 2005 9:03 PM, Kelly Leahy <kellyleahy at swbell.net> wrote:
> 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
> >
>