New size optimization

New size optimization

[Joern Rennecke]

Invariant code motion in general adds extra moves and register pressure.
AFAIK there are no common scenarios where it can be a precursor for
another optimization that leads to a code size saving.  Thus, I think it
should be turned off when optimizing for space.

I found this while trying to improve giv finding on the SH by correcting
RTX costs, and found that some other code increased significantly in size:
it went from 949 bytes to 997.
However, with the patch below, it went down to 893 bytes.

Mon Mar 30 23:43:58 1998  J"orn Rennecke <amylaar@cygnus.co.uk>

	* loop.c (scan_loop): Don't call move_moveables for optimize_size.

Index: loop.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gcc/loop.c,v
retrieving revision 1.125
diff -p -r1.125 loop.c
*** loop.c	1998/03/25 18:34:32	1.125
--- loop.c	1998/03/30 22:44:19
*************** scan_loop (loop_start, end, nregs, unrol
*** 1052,1059 ****
    /* Now consider each movable insn to decide whether it is worth moving.
       Store 0 in n_times_set for each reg that is moved.  */
  
!   move_movables (movables, threshold,
! 		 insn_count, loop_start, end, nregs);
  
    /* Now candidates that still are negative are those not moved.
       Change n_times_set to indicate that those are not actually invariant.  */
--- 1052,1060 ----
    /* Now consider each movable insn to decide whether it is worth moving.
       Store 0 in n_times_set for each reg that is moved.  */
  
!   if (! optimize_size)
!     move_movables (movables, threshold,
! 		   insn_count, loop_start, end, nregs);
  
    /* Now candidates that still are negative are those not moved.
       Change n_times_set to indicate that those are not actually invariant.  */

Re: New size optimization

[Jim Wilson]

I was talking to Anthony Green about this, and he mentioned that it might be
useful to add a flag to disable loop-invariant-code-motion and then have -Os
set that flag.  That is, we perhaps should make -Os work like -O2.  -O2 just
sets a bunch of flags, and the user can override the choices if they are wrong
for a particular application.  We should perhaps do the same for -Os, making
it set a bunch of flags that the user can override if the defaults weren't the
best possible choice.  There is a tradeoff with having too many -f options
that the user gets confused though.

Is there any reason why you just disabled the last part of the LICM code, and
not all of it?  Maybe strength reduction needs some of the info computed by
LICM.  Or maybe you didn't try disabling the rest of it?  It is probably useful
to document why this choice was made in a comment.

Jim

Re: New size optimization

[Joern Rennecke]

> I was talking to Anthony Green about this, and he mentioned that it might be
> useful to add a flag to disable loop-invariant-code-motion and then have -Os
> set that flag.  That is, we perhaps should make -Os work like -O2.  -O2 just
> sets a bunch of flags, and the user can override the choices if they are wrong
> for a particular application.  We should perhaps do the same for -Os, making
> it set a bunch of flags that the user can override if the defaults weren't the
> best possible choice.  There is a tradeoff with having too many -f options
> that the user gets confused though.
> 
> Is there any reason why you just disabled the last part of the LICM code, and
> not all of it?  Maybe strength reduction needs some of the info computed by
> LICM.  Or maybe you didn't try disabling the rest of it?  It is probably useful
> to document why this choice was made in a comment.

I didn't try disabling the rest.
The patch I made is simple and allows quick testing.
I don't know if disabling the rest will require any special attention on
data that is used by other code; at any rate, it would require a lot of
indentation changes, or lots of small changes involving the flag to test,
or both.
So before we do that, I think we should decide if we want a new -f option
for this choice - and if yes, how its flag variable is called.

Re: New size optimization

[Jeffrey A Law]

  In message < 199803302250.XAA27657@phal.cygnus.co.uk >you write:
  > Invariant code motion in general adds extra moves and register pressure.
  > AFAIK there are no common scenarios where it can be a precursor for
  > another optimization that leads to a code size saving.  Thus, I think it
  > should be turned off when optimizing for space.
Sure it can -- moving an invariant out of a loop may expose it to
local optimizations in the block before the loop (cse, combine, etc).

I'm not saying disabling loop invariant code motion is the wrong 
thing to do when optimizing for size -- it's just not as cut and
dried as you made it seem to be.

jeff

Re: New size optimization

[Jeffrey A Law]

  In message < 199804010031.QAA06136@rtl.cygnus.com >you write:
  > I was talking to Anthony Green about this, and he mentioned that
  > it might be useful to add a flag to disable loop-invariant-code-motion and then have -Os
  > set that flag.
Not a bad idea.

Then again, as you mention, we could end up with too man -f flags.  Some
might even say we already have too many -f flags :-)

I've got no strong opinion either way, I'll go with any decision folks
want.

jeff

New size optimization

[Joern Rennecke]

Invariant code motion in general adds extra moves and register pressure.
AFAIK there are no common scenarios where it can be a precursor for
another optimization that leads to a code size saving.  Thus, I think it
should be turned off when optimizing for space.

I found this while trying to improve giv finding on the SH by correcting
RTX costs, and found that some other code increased significantly in size:
it went from 949 bytes to 997.
However, with the patch below, it went down to 893 bytes.

Mon Mar 30 23:43:58 1998  J"orn Rennecke <amylaar@cygnus.co.uk>

	* loop.c (scan_loop): Don't call move_moveables for optimize_size.

Index: loop.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gcc/loop.c,v
retrieving revision 1.125
diff -p -r1.125 loop.c
*** loop.c	1998/03/25 18:34:32	1.125
--- loop.c	1998/03/30 22:44:19
*************** scan_loop (loop_start, end, nregs, unrol
*** 1052,1059 ****
    /* Now consider each movable insn to decide whether it is worth moving.
       Store 0 in n_times_set for each reg that is moved.  */
  
!   move_movables (movables, threshold,
! 		 insn_count, loop_start, end, nregs);
  
    /* Now candidates that still are negative are those not moved.
       Change n_times_set to indicate that those are not actually invariant.  */
--- 1052,1060 ----
    /* Now consider each movable insn to decide whether it is worth moving.
       Store 0 in n_times_set for each reg that is moved.  */
  
!   if (! optimize_size)
!     move_movables (movables, threshold,
! 		   insn_count, loop_start, end, nregs);
  
    /* Now candidates that still are negative are those not moved.
       Change n_times_set to indicate that those are not actually invariant.  */

----- End of forwarded message from Joern Rennecke -----

Re: New size optimization

[Jeffrey A Law]

  In message <199803302250.XAA27657@phal.cygnus.co.uk>you write:
  > Invariant code motion in general adds extra moves and register pressure.
  > AFAIK there are no common scenarios where it can be a precursor for
  > another optimization that leads to a code size saving.  Thus, I think it
  > should be turned off when optimizing for space.
  > 
  > I found this while trying to improve giv finding on the SH by correcting
  > RTX costs, and found that some other code increased significantly in size:
  > it went from 949 bytes to 997.
  > However, with the patch below, it went down to 893 bytes.
  > 
  > Mon Mar 30 23:43:58 1998  J"orn Rennecke <amylaar@cygnus.co.uk>
  > 
  > 	* loop.c (scan_loop): Don't call move_moveables for optimize_size.
No sense in not getting the benefit of this patch while we decide
if it should have it's own flag :-)

I expanded the comment a little and installed the patch.

jeff