[Mono-devel-list] Re: [Mono-patches] r40869 - trunk/mcs/mcs

[Ben Maurer]

On Mon, 2005-02-21 at 08:17 +0000, Marek Safar wrote:
> I really don't know how many people would like to do it. But if we will 
> not emit such fields by default nobody can ever do it.
> 
> here is another example of code that is optimized
> 
> class C
> {
>     enum E
>     {
>         Test
>     }
>     E e = E.Test;    // You cannot insert breakpoint here
> }
> 
> Are you still confident ?

If somebody needs to set a breakpoint on the ctor, they will set it
there (by explicitly writing public C () {}, and adding a breakpoint),
not by breaking on a field init.

Breaking on something like this is about as uninteresting as it gets. I
see no reason to support it.


> >For now, the thing of setting /optimize to true by default works.
> >However, if we were to add more expensive optimizations (for example,
> >csc will do a round of jump optimizations), it would be nice to keep the
> >`duh' type ones on by default.
> >  
> >
> I don't think so, it is only about 'how is it expensive". We simply do 
> not emit what an user wrote. This is very similar case as
> warning CS0219. It is also not expensive. Should we optimalize such code 
> out by default as well?

If the code was not compiled with --debug and not with /o+, I think it
should be removed. Without --debug, there is no way the user wanted to
run the code in a debugger anyways, so why not just remove the
variable? /o+ says that the user is willing to make some sacrifices in
debugability for optimization.

Remember, in the msft jit, if you are *not* in debug mode, the following
code:

int a = GetFoo ();

Console.WriteLine (a);

int b = GetBar ();

Console.WriteLine (b);

The variables `a' and `b' will use the same stack slot or register.
However, if you are running in a debugger, they will use different stack
slots. Why? because somebody running under the debugger might want to
see what the value of `a' was when they are at the end of this block.


> >(nb, I realize that jump optimizations are done by the jit, etc. But
> >there might be other more expensive optimizations that are not done by
> >the jit, or optimizations that are so expensive that they would only be
> >done at aot time, so that it would be cool to do them at compile time as
> >well.)
> >  
> >
> I think jump/try/catch optimalizations are done by ILASM and not primary 
> by compiler (in Microsoft model).

The msft compiler does not use ilasm.

-- Ben