[Mono-bugs] [Bug 54917][Wis] Changed - We miss some optimizations with callvirt

[bugzilla-daemon@bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by bmaurer@users.sf.net.

http://bugzilla.ximian.com/show_bug.cgi?id=54917

--- shadow/54917	2004-02-27 17:49:00.000000000 -0500
+++ shadow/54917.tmp.21873	2004-02-28 11:08:06.000000000 -0500
@@ -1,13 +1,13 @@
 Bug#: 54917
 Product: Mono/Compilers
 Version: unspecified
 OS: unknown
 OS Details: 
-Status: RESOLVED   
-Resolution: FIXED
+Status: REOPENED   
+Resolution: 
 Severity: Unknown
 Priority: Wishlist
 Component: C#
 AssignedTo: mono-bugs@ximian.com                            
 ReportedBy: bmaurer@users.sf.net               
 QAContact: mono-bugs@ximian.com
@@ -68,6 +68,50 @@
 ------- Additional Comments From miguel@ximian.com  2004-02-27 17:48 -------
 Interesting, this seems like a regression in the compiler, I remember
 fixing this before.
 
 Anyways, this gave us one tenth of a second improvement on a 3 second
 build of the Mono C# compiler. 
+
+------- Additional Comments From bmaurer@users.sf.net  2004-02-28 11:08 -------
+Ok, some updates here:
+
+1) We found out that you sometimes need to emit callvirt to get the
+null check.
+
+2) I had to fix miguel's patch to account for ^. Right now, we only do
+the optimization on a construct such as:
+
+this.Foo ();
+
+Because we know that this cant be null
+
+However, we can do much better. Lets say you had the following code:
+
+MyClass foo = new MyClass ();
+
+foo.Bar (); // (1)
+
+you know that foo cant be null at (1) because a constructor always
+gives a non null object. Also, consider:
+
+for (int i = 0; i < 10000000; i ++) {
+    MyClass foo = GetMyFoo ();
+    foo.Bar (); // (1)
+    foo.Baz (); // (2)
+    foo.Blah (); // (3)
+}
+
+At (1) we have to do the null check, because the object could be null.
+However, we cant reach (2) if foo is null because it would have thrown
+an exception at (1). So we could avoid two null checks here.
+
+Also, we often have constructs such as:
+
+if (foo != null) { foo.Blah (); }
+
+So, foo cant be null at the call there.
+
+Not sure how many cases we can get here. But given that MCS showed a
+3% improvement if we (wrongly) did all cases, I think we might be able
+to get a good portion of that improvement without regressions. Even a
+1% global increase would be *very* cool.