X-Git-Url: http://wien.tomnetworks.com/gitweb/?a=blobdiff_plain;f=docs%2Fabc-removal.txt;h=5c2ce91fd5f294e7a96b347bdb5f69200022c2c9;hb=4058c2be43ec605cdcc57e9d678251339349cb5f;hp=b44089c0de9ac4d5a5269fd91a6a4c8301f9c950;hpb=2279f440996923ac66a6ea85cf101d89615aad69;p=mono.git

diff --git a/docs/abc-removal.txt b/docs/abc-removal.txt
index b44089c0de9..5c2ce91fd5f 100755
--- a/docs/abc-removal.txt
+++ b/docs/abc-removal.txt
@@ -26,7 +26,7 @@ some combination of the two.
 	
 	To be clearer, and give an idea of what the algorithm can and
 	cannot do without describing it in detail... keep in mind that
-	only "redunant" checks cannot be removed. By "redundant", I
+	only "redundant" checks cannot be removed. By "redundant", I
 	mean "already explicitly checked" in the method code.
 	
 	Unfortunately, analyzing complex expressions is not so easy
@@ -136,7 +136,7 @@ some combination of the two.
 	In the first case, the BB has exactly two exit BBs, and their
 	execution conditions are easy to get from the condition of the
 	branch (see the "get_relation_from_branch_instruction"
-	function, and expecially the end of "analyze_block" in
+	function, and especially the end of "analyze_block" in
 	abcremoval.c.
 
 	If there is a switch, the jump condition of every exit BB is
@@ -303,7 +303,7 @@ some combination of the two.
 	each BB tried to examine all possible conditions between all
 	variables, filling a sort of "evaluation matrix". The problem
 	was that the complexity of this evaluation was quadratic (or
-	worse) on the number of variables, and that many wariables
+	worse) on the number of variables, and that many variables
 	were examined even if they were not involved in any array
 	access.
 	
@@ -332,7 +332,7 @@ some combination of the two.
 
 		    [1b] Prepare the evaluation graph (empty)
 
-		    [1b] Summarize each varible definition, and put
+		    [1b] Summarize each variable definition, and put
 		         the resulting relations in the evaluation
 		         graph