[Mono-dev] CIL to CIL optimizer

[Zoltan Varga]

        Hi,

  Our JIT basically turns off a lot of stuff when dealing with methods with
exception clauses, for the previously mentioned reasons.

         Zoltan

On 8/10/06, Rafael Teixeira <monoman at gmail.com> wrote:
> Have you looked into the implementation of the SSA optimizations our
> JIT already does?
> You may find useful insights on it, even if it optimizes not CIL but
> another intermediary representation and targets native instructions.
>
> :)
>
> On 8/10/06, Bjarke Hammersholt Roune <bjarke.roune at gmail.com> wrote:
> > Zoltan Varga skrev:
> >  >                                      Hi,
> >  >
> >  >   What is the problem with try-finally ? There are two cases:
> >  > - if there is an exception, the runtime will call it, just with the
> > catch clause
> >  > - if there is no exception, control flow just falls from the end of
> >  > the try block to
> >  > the beginning of the finally block. This is just a normal control
> > flow edge.
> >  >
> > The problem is that what happens after the finally block is done depends
> > on the context that caused it to run. Here is a simple example in pseudo
> > code:
> >
> >         try {
> >                 if (a) {
> > A:                      x = 2;
> >                         goto E;
> >                 }
> > B:              x = 1;
> >         } finally {
> > C:              print "hello world!";
> >         }
> > D:      print x;
> > E:      return
> >
> > Imagine a control flow graph of this code with the labels naming the
> > nodes. Then there will be edges A->C, B->C, C->D, C->E and D->E. The
> > definition of x that reaches D will thus have to go through C, and then
> > C will need a phi-function to get the correct definition of x. This will
> > make it look like the definition of x from A is needed at C, even though
> > obviously it is not. The basic problem is that the control flow graph
> > makes it look like the path A->C->D is possible. In this example this
> > means that we cannot discover that x=2 is dead code.
> >
> > Suppose that the x=2 at A was something throwing an exception instead
> > and we had a catch handler on the innermost try. Then C would need an
> > outgoing edge to this handler, making it look like falling through at B
> > could cause an exception!
> >
> > So if we don't do something special for finally, we can get preposterous
> >   information. I should perhaps say that I am interested in precise
> > analysis to do good optimization, but also because I would like the
> > program to have capabilities similar to the Java findbugs program,
> > though that would not be a priority at first.
> >
> > I am sure this CAN be fixed for each analysis by doing the equivalent of
> > path sensitive analysis but restricting it to finally. Basically this
> > will be the same thing as making the analysis act as if the finally
> > block was inlined everywhere it could be called, but without actually
> > inlining it. I am not sure how that should interact with SSA-form.
> >
> > Even if we use the naive approach the control flow graph will need to
> > know that removing an edge TO a finally block might or might not
> > necessitate removing an edge FROM it, depending on whether or not a
> > different branch from inside the corresponding try block has another
> > branch that needs to go the same outer destination. If that does not
> > make sense consider removing the last branch to a label outside a
> > finally-protected try block as compared to removing one of several
> > branches that all go to the same label outside the try block.
> >
> > I expect to discover more of these kinds of differences from normal
> > control flow graph behavior as implementation proceeds, since finally
> > directs control flow in a different way from anything else.
> >
> > I hope I have convincingly argued that finally needs special treatment
> > and that that treatment is non-trivial if we need reasonably precise
> > analysis of program behavior.
> >
> > /Bjarke
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
>
>
> --
> Rafael "Monoman" Teixeira
> ---------------------------------------
> "The reasonable man adapts himself to the world; the unreasonable one
> persists in trying to adapt the world to himself. Therefore all
> progress depends on the unreasonable man." George Bernard Shaw
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>