[PATCH] Don't emit cmpstrsi and movstr* insns with -Os

Roger Sayle roger@eyesopen.com
Sat Sep 6 23:19:00 GMT 2003


The following patch disables use of cmpstrsi and movstr* instructions
when optimizing for size.  An analysis of -fno-builtin on the CSiBE
GCC code size benchmark, http://sed.inf.u-szeged.hu/csibe/, revealed
that we often produced smaller code when disabling GCC's builtins.
On x86, the two main culprits appear to be strcmp and memcpy.  It
transpires that setting up the registers to use the cmpstrsi and
movstr* patterns typically requires more space than a function call,
and adversely affects register pressure.

CSiBE results for i686-pc-linux-gnu with -Os:

			  size (bytes)
	CVS mainline		989455
	disable cmpstrsi	987480	-1975
	disable movstr*		988905	 -505
	disable both		986795	-2660

When disabling both, 54 tests decrease in size, several by a few hundred
bytes, and only eight increase in size.  The worst increase is 15 bytes,
with the majority of the increases being only by a byte or two.

Disabling cmpstrsi with -Os shouldn't be controversial, the only backend
.md file that defines a pattern for it is i386.md.  My belief is that
disabling movstr* should also be a space win on other platforms, most of
which don't have the CISC advantages of x86's variable instruction length
encoding, complex memory move instructions and unaligned memory accesses.

However if someone does find net size regression for their target on
CSiBE, we can always re-evaluate this second hunk.  The poor -Os
parameterization of most backends (for example, most targets' RTX_COST
implementations don't even check optimize_size) makes it preferable to
solve these issues in the middle-end if possible.


The following patch has been tested on i686-pc-linux-gnu with a complete
"make bootstrap", all languages except treelang, and regression tested
with a top-level "make -k check" with no new failures.

Ok for mainline?


2003-09-06  Roger Sayle  <roger@eyesopen.com>

	* builtins.c (expand_builtin_strcmp): Don't use cmpstrsi with -Os.
	* expr.c (emit_block_move): Don't use emit_block_move_via_movstr
	with -Os if we can make a libcall instead.


Index: builtins.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/builtins.c,v
retrieving revision 1.249
diff -c -3 -p -r1.249 builtins.c
*** builtins.c	4 Sep 2003 23:03:50 -0000	1.249
--- builtins.c	6 Sep 2003 19:18:08 -0000
*************** expand_builtin_strcmp (tree exp, rtx tar
*** 3281,3287 ****
      }

  #ifdef HAVE_cmpstrsi
!   if (HAVE_cmpstrsi)
    {
      tree len, len1, len2;
      rtx arg1_rtx, arg2_rtx, arg3_rtx;
--- 3281,3287 ----
      }

  #ifdef HAVE_cmpstrsi
!   if (HAVE_cmpstrsi && ! optimize_size)
    {
      tree len, len1, len2;
      rtx arg1_rtx, arg2_rtx, arg3_rtx;
Index: expr.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/expr.c,v
retrieving revision 1.582
diff -c -3 -p -r1.582 expr.c
*** expr.c	4 Sep 2003 03:17:46 -0000	1.582
--- expr.c	6 Sep 2003 19:18:10 -0000
*************** emit_block_move (rtx x, rtx y, rtx size,
*** 1775,1783 ****
        set_mem_size (y, size);
      }

!   if (GET_CODE (size) == CONST_INT && MOVE_BY_PIECES_P (INTVAL (size), align))
      move_by_pieces (x, y, INTVAL (size), align, 0);
!   else if (emit_block_move_via_movstr (x, y, size, align))
      ;
    else if (may_use_call)
      retval = emit_block_move_via_libcall (x, y, size);
--- 1775,1785 ----
        set_mem_size (y, size);
      }

!   if (GET_CODE (size) == CONST_INT
!       && MOVE_BY_PIECES_P (INTVAL (size), align))
      move_by_pieces (x, y, INTVAL (size), align, 0);
!   else if ((! optimize_size || ! may_use_call)
! 	   && emit_block_move_via_movstr (x, y, size, align))
      ;
    else if (may_use_call)
      retval = emit_block_move_via_libcall (x, y, size);


Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833



More information about the Gcc-patches mailing list