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

[Zoltan Varga]

                                      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
> 
>