Fix for condexec problems in flow.c

Jan Hubicka jh@suse.cz
Tue Mar 13 02:50:00 GMT 2001


Hi
Here is an attempt to fix the dataflow problem - it seems to be safe for me
to use reversed_comparison_code and if that fails, fall out to the FP
reversals, that should be always safe to prove disjuncness of the paths
(or is the whole beast used for something else too?)

There is still problem in the and_reg_cond, that does use
reverse_comparison_code to prove disjuncness. There is infrastructure bit
REVERSE_CONDEXEC_PREDICATES.  It seems to me, that this one should get whole
conditions and do the same trick as I do elsewhere by default.

Honza

Tue Mar 13 11:46:59 CET 2001  Jan Hubicka  <jh@suse.cz>

	* flow.c (init_propagate_block_info): Use reversed_comparison_code
	and reverse_condition_maybe_unordered to do the reversal.
	(not_reg_cond): Likewise.

Index: flow.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/flow.c,v
retrieving revision 1.382
diff -c -3 -p -r1.382 flow.c
*** flow.c	2001/03/12 19:09:56	1.382
--- flow.c	2001/03/13 10:46:10
*************** init_propagate_block_info (bb, live, loc
*** 4135,4140 ****
--- 4135,4141 ----
        regset diff = INITIALIZE_REG_SET (diff_head);
        basic_block bb_true, bb_false;
        rtx cond_true, cond_false, set_src;
+       enum rtx_code reversed_code;
        int i;
  
        /* Identify the successor blocks.  */
*************** init_propagate_block_info (bb, live, loc
*** 4165,4171 ****
        /* Extract the condition from the branch.  */
        set_src = SET_SRC (pc_set (bb->end));
        cond_true = XEXP (set_src, 0);
!       cond_false = gen_rtx_fmt_ee (reverse_condition (GET_CODE (cond_true)),
  				   GET_MODE (cond_true), XEXP (cond_true, 0),
  				   XEXP (cond_true, 1));
        if (GET_CODE (XEXP (set_src, 1)) == PC)
--- 4166,4182 ----
        /* Extract the condition from the branch.  */
        set_src = SET_SRC (pc_set (bb->end));
        cond_true = XEXP (set_src, 0);
!       reversed_code = reversed_comparison_code (cond_true, bb->end);
! 
!       /* In case we failed to do the reversal, do the unordered reversal.
!          This is safe - for integer comparisons it will just make us overhelmly
!          curefull about priving condition mutex and for floating point
! 	 comparisons it is correct.  We never write back the condition to rtl
! 	 stream, so we don't need to worry about converting nontrapping compare
! 	 to trapping.  */
!       if (reversed_code == UNKNOWN)
! 	reversed_code = reverse_condition_maybe_unordered (GET_CODE (cond_true));
!       cond_false = gen_rtx_fmt_ee (reversed_code,
  				   GET_MODE (cond_true), XEXP (cond_true, 0),
  				   XEXP (cond_true, 1));
        if (GET_CODE (XEXP (set_src, 1)) == PC)
*************** not_reg_cond (x)
*** 5345,5354 ****
    if (GET_RTX_CLASS (x_code) == '<'
        && GET_CODE (XEXP (x, 0)) == REG)
      {
        if (XEXP (x, 1) != const0_rtx)
  	abort ();
  
!       return gen_rtx_fmt_ee (reverse_condition (x_code),
  			     VOIDmode, XEXP (x, 0), const0_rtx);
      }
    return gen_rtx_NOT (0, x);
--- 5356,5369 ----
    if (GET_RTX_CLASS (x_code) == '<'
        && GET_CODE (XEXP (x, 0)) == REG)
      {
+       enum rtx_code reversed_code;
        if (XEXP (x, 1) != const0_rtx)
  	abort ();
  
!       reversed_code = reversed_comparison_code (x, NULL);
!       if (reversed_code == UNKNOWN)
! 	reversed_code = reverse_condition_maybe_unordered (x_code);
!       return gen_rtx_fmt_ee (reversed_code,
  			     VOIDmode, XEXP (x, 0), const0_rtx);
      }
    return gen_rtx_NOT (0, x);



More information about the Gcc-patches mailing list