CSE fold_rtx subreg patch

John Wehle john@feith.com
Mon Jul 13 00:24:00 GMT 1998


> I'm also a little worried about the < to <= changes, particularly for
> SUBREGS since they are not optimized as well as REGs in other passes
> and thus "cost more".  Presumably you added it because the cases you
> tried had equal cost.

Instead of changing fold_rtx so it propagates subregs, another
approach is to change cse_insn so that it doesn't propagate
subregs (the issue, after all, is to simply be consistent).
The enclosed patch is an alternative to the earlier fold_rtx
patch and also results in better code then the unpatched cse.c
when compiling:

  unsigned char c;

  int
  func(unsigned char a)
    {
    unsigned char b;
 
    b = a;
    c = b;

    return b;
    }

on the i386.

ChangeLog:

Mon Jul 13 02:51:26 EDT 1998  John Wehle  (john@feith.com)

	* cse.c (cse_insn): Don't consider replacing src with a
	subreg unless we're looking for a paradoxical subreg.

Enjoy!

-- John Wehle
------------------8<------------------------8<------------------------
*** gcc/cse.c.ORIGINAL	Sat Jul 11 02:17:16 1998
--- gcc/cse.c	Mon Jul 13 02:43:04 1998
***************
*** 6772,6783 ****
  	  if (code != REG && ! exp_equiv_p (p->exp, p->exp, 1, 0))
  	    continue;
  
! 	  /* Also skip paradoxical subregs, unless that's what we're
! 	     looking for.  */
  	  if (code == SUBREG
! 	      && (GET_MODE_SIZE (GET_MODE (p->exp))
! 		  > GET_MODE_SIZE (GET_MODE (SUBREG_REG (p->exp))))
! 	      && ! (src != 0
  		    && GET_CODE (src) == SUBREG
  		    && GET_MODE (src) == GET_MODE (p->exp)
  		    && (GET_MODE_SIZE (GET_MODE (SUBREG_REG (src)))
--- 6772,6784 ----
  	  if (code != REG && ! exp_equiv_p (p->exp, p->exp, 1, 0))
  	    continue;
  
! 	  /* Also skip subregs (which prevents register allocation problems
! 	     due CSE inconsistencies in the substitution of subregs for regs),
! 	     unless we're looking for paradoxical subregs.  */
  	  if (code == SUBREG
! 	      && ! (GET_MODE_SIZE (GET_MODE (p->exp))
! 			> GET_MODE_SIZE (GET_MODE (SUBREG_REG (p->exp)))
! 		    && src != 0
  		    && GET_CODE (src) == SUBREG
  		    && GET_MODE (src) == GET_MODE (p->exp)
  		    && (GET_MODE_SIZE (GET_MODE (SUBREG_REG (src)))
***************
*** 6858,6873 ****
  	         && ! exp_equiv_p (elt->exp, elt->exp, 1, 0))
  	    elt = elt->next_same_value;	     
  
! 	  /* A paradoxical subreg would be bad here: it'll be the right
! 	     size, but later may be adjusted so that the upper bits aren't
! 	     what we want.  So reject it.  */
  	  if (elt != 0
  	      && GET_CODE (elt->exp) == SUBREG
! 	      && (GET_MODE_SIZE (GET_MODE (elt->exp))
! 		  > GET_MODE_SIZE (GET_MODE (SUBREG_REG (elt->exp))))
! 	      /* It is okay, though, if the rtx we're trying to match
! 		 will ignore any of the bits we can't predict.  */
! 	      && ! (src != 0
  		    && GET_CODE (src) == SUBREG
  		    && GET_MODE (src) == GET_MODE (elt->exp)
  		    && (GET_MODE_SIZE (GET_MODE (SUBREG_REG (src)))
--- 6859,6876 ----
  	         && ! exp_equiv_p (elt->exp, elt->exp, 1, 0))
  	    elt = elt->next_same_value;	     
  
! 	  /* Skip subregs (which prevents register allocation problems due
! 	     CSE inconsistencies in the substitution of subregs for regs),
! 	     unless we're looking for paradoxical subregs.  */
  	  if (elt != 0
  	      && GET_CODE (elt->exp) == SUBREG
! 	      && ! (GET_MODE_SIZE (GET_MODE (elt->exp))
! 			> GET_MODE_SIZE (GET_MODE (SUBREG_REG (elt->exp)))
! 	      /* A paradoxical subreg would be bad here: it'll be the right
! 		 size, but later may be adjusted so that the upper bits aren't
! 		 what we want.  So reject it unless the rtx we're trying to
! 		 match will ignore any of the bits we can't predict.  */
! 		    && src != 0
  		    && GET_CODE (src) == SUBREG
  		    && GET_MODE (src) == GET_MODE (elt->exp)
  		    && (GET_MODE_SIZE (GET_MODE (SUBREG_REG (src)))
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------




More information about the Gcc-patches mailing list