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

[Marek Safar]

Hello,

>>>I don't see any reason to require /optimize here. This is an
>>>optimization that takes O(1) time, where the constant is *very* small.
>>>
>>>Personally, I think /optimize should only be used to enable expensive
>>>optimizations. The goal of the flag is so that the default compile will
>>>take shorter.
>>>      
>>>
>>Marek said that the reason was that you could not set a breakpoint in
>>that line if you optimize the code away.  
>>
>>I also think this should just be done always, and that not being able to
>>set a breakpoint in that line wont hurt.
>>    
>>
>
>Yeah, I am not sure how many people need to set a breakpoint on public
>int foo = 0. :-).
>  
>
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 ?

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

>(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).

Regards,
Marek