re-enable cmov conversion

Richard Henderson rth@cygnus.com
Mon Oct 4 11:38:00 GMT 1999


I noticed last night that Alpha wasn't doing cmov if-conversion any more. 

The reason is that it gets HAVE_conditional_arithmetic defined (which it
doesn't really have -- just cmov float_extend sf->df).  One of the changes
with HAVE_conditional_arithmetic is that we don't do if-conversion before
cse, and the test used is cse_not_expected.

Except that cse_not_expected is set after the jump pass after cse2, there
is no other jump pass run until after reload, and we don't do cmov conversion
after reload.

This is the best solution I could think of.  It's not even too wrong if
you look at it from the point of view of "while the last cse is running,
we shouldn't expect another cse pass".


r~


        * toplev.c (rest_of_compilation): Turn on cse_not_expected
        before cse2 instead of after.

Index: toplev.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/toplev.c,v
retrieving revision 1.234
diff -c -p -d -r1.234 toplev.c
*** toplev.c	1999/10/02 20:13:24	1.234
--- toplev.c	1999/10/04 18:27:53
*************** rest_of_compilation (decl)
*** 3856,3861 ****
--- 3856,3866 ----
  	ggc_collect ();
      }
  
+   /* ??? Well, nearly.  If HAVE_conditional_arithmetic, jump_optimize
+      has put off all if-conversion until "after CSE".  If we put this
+      off any longer we may miss out doing if-conversion entirely.  */
+   cse_not_expected = 1;
+ 
    if (optimize > 0)
      {
        if (cse2_dump)
*************** rest_of_compilation (decl)
*** 3924,3933 ****
        if (ggc_p)
  	ggc_collect ();
      }
- 
-   /* We are no longer anticipating cse in this function, at least.  */
- 
-   cse_not_expected = 1;
  
    /* Now we choose between stupid (pcc-like) register allocation
       (if we got the -noreg switch and not -opt)
--- 3929,3934 ----


More information about the Gcc-patches mailing list