[Mono-bugs] [Bug 35894][Wis] Changed - reduce size of produced binaries

[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=35894

--- shadow/35894	2003-01-31 11:30:59.000000000 -0500
+++ shadow/35894.tmp.31618	2004-01-04 21:41:47.000000000 -0500
@@ -24,6 +24,47 @@
 4) use short branch opcodes
 
 1 and 2 are the items more worth it.
 
 ------- Additional Comments From lupus@ximian.com  2003-01-31 11:30 -------
 Item 2 and 3 are already done.
+
+------- Additional Comments From bmaurer@users.sf.net  2004-01-04 21:41 -------
+For case (4) we could make S.R.E emit a short branch if the label has
+already been marked. For example:
+
+static void Foo ()
+{
+int x = 0;
+
+loop:
+    x ++
+
+if (x < 500) goto loop;
+}
+
+which is basically what we generate for:
+
+for (int x = 0; x < 100; x ++)
+    ;
+
+Doing it on a forwards branch would be *much* harder. The only case I
+can think of that would be remotely fast is that if you have code like
+this:
+
+if (x == 0)
+    return;
+...
+
+In this case, S.R.E would see the following
+
+ldarg.1
+brfalse <mark>
+ret
+<label mark>
+
+So, what we could do is allocate enough space for the brfalse to be a
+long jump, but if it ends up being short, we just copy everything up.
+However, this would not work so well if there were a fixup between the
+ jump and the mark. Do we really save enough to make this worth it? I
+think the first case is worth it (it is a 5 minute hack), but i am not
+convinced at all about the second.