[Mono-bugs] [Bug 71576][Wis] Changed - ABCREM should obtain relationship info from % operators

[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 massi@ximian.com.

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

--- shadow/71576	2005-01-23 03:02:46.000000000 -0500
+++ shadow/71576.tmp.12578	2005-01-24 07:18:12.000000000 -0500
@@ -1,12 +1,12 @@
 Bug#: 71576
 Product: Mono: Runtime
 Version: unspecified
 OS: unknown
 OS Details: 
-Status: NEW   
+Status: ASSIGNED   
 Resolution: 
 Severity: Unknown
 Priority: Wishlist
 Component: JIT
 AssignedTo: mono-bugs@ximian.com                            
 ReportedBy: vargaz@gmail.com               
@@ -61,6 +61,62 @@
 Actually, in your test case, we should probably fold the mod up into a
 mod.un. It is going to be faster (at least on x86), and require fewer
 bytes of code (no cdq). Also, if that 10 were a 16, it would allow us
 to avoid the div completely.
 
 I think ABCREM has the code to do this.
+
+------- Additional Comments From massi@ximian.com  2005-01-24 07:18 -------
+
+Well, two different comments...
+
+First of all, yes, the '%' operator could be handled by ABCREM,
+but currently not in a complete way.
+
+The problem is that the 'X = A % B' tells us that the absolute
+value of X is less than the absolute value of B, and the sign
+of X is equal to the sign of A.
+
+If both A and B are positive, this means 'X < B'.
+The problem is that, in the general case, it is likely that
+ABCREM will discover the fact that A and B are positive *later*
+in the relation graph traversal.
+This would happen in the typical "for (int i = 0; i < 100; ++i)"
+loop, like in the first example: 'i' is clearly positive, but
+ABCREM must deduce it from the evaluation graph.
+
+So, in the particular case in which A and B are either constants
+or declared unsigned, adding support to '%' is really trivial (all
+the information is available immediately).
+For the general case, I should add the notion of "absolute value"
+to the graph, and deal with it in the graph traversal engine.
+Realistically, this could take from some day to a week (including
+proper debugging and testing).
+This would also allow partial handling of other operations, like
+right shifts or integer divisions (I remember I couldn't handle
+them just because of this reason).
+
+Personally, given the fact that programmers (me included) never
+use unsigned variables in loops like the one above, I'd go for
+the general solution, but I'd like to see what others think of it.
+
+Second comment, to Ben's idea: yes, ABCREM has the code to do
+it (it is basically what I explained above).
+I remember we had in mind to extend the use of this code for
+more than ABCREM, including NULL pointer and "is a" checks, and
+this could be yet another extension.
+
+How to do this *and* keep the code clean (well, at least as much
+as possible) is a different thing ;-)
+I have some idea to make the evaluation graph a sort of "global"
+piece of information (I mean put it inside a MonoCompile), and
+exporting some methods to do the actual evaluations, so that each
+individual optimization that needs to know something (like, "is
+X >= 0 in this BB?", or "is Y != NULL?") can query for it.
+ABCREM would become a special case among many others.
+
+This, however, would be long term goal, as it raises a number of
+subtle issues which is not the case to write here.
+
+In any case, doing it in a hackish way inside the abcrem.c file
+is not that hard, I just wonder if it's really the case :-)
+