[Mono-dev] CIL to CIL optimizer

Rafael Teixeira monoman at gmail.com
Thu Aug 10 09:00:36 EDT 2006

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

More information about the Mono-devel-list mailing list