This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

ARM: allow factorization of constants into addressing insns whenoptimizing for space


If optimizing for space, we currently let the compiler synthesize constants
only if they need one insn, otherwise a load from memory is performed.

This patch allows the compiler to synthesize constants with up to 2 insns,
which uses the same space as a load from memory (the ldr insn and the pool
entry) so worse case is the same. HOwever, this gives the opportunity to
take even less space when different offsets can be factorized and combined
into multiple pre-indexed loads or stores.

Testing shows varying degree of text size reduction depending on code 
patern.  No increase of code space has been noted.

This patch also restructure related code a bit with some more comments to
make things clearer but with no other operational changes.


<date>  Nicolas Pitre <nico@cam.org>

	* config/arm/arm.c (arm_override_options): Set arm_constant_limit
	to 2 instead of 1 when optimize_size is true.  Gather code based on
	optimize_size together.  Add comment about XScale load latency.


Index: config/arm/arm.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/arm/arm.c,v
retrieving revision 1.299
diff -u -r1.299 arm.c
--- config/arm/arm.c	19 Oct 2003 01:01:46 -0000	1.299
+++ config/arm/arm.c	19 Oct 2003 01:25:29 -0000
@@ -831,23 +831,34 @@
       flag_schedule_insns = 0;
     }
 
-  /* If optimizing for space, don't synthesize constants.
-     For processors with load scheduling, it never costs more than 2 cycles
+  /* For processors with load scheduling, it never costs more than 2 cycles
      to load a constant, and the load scheduler may well reduce that to 1.  */
-  if (optimize_size || (tune_flags & FL_LDSCHED))
+  if (tune_flags & FL_LDSCHED)
     arm_constant_limit = 1;
-  
+
+  /* On XScale the longer latency of a load makes it more difficult to
+     achieve a good schedule, so it's always faster to synthesize constants
+     that can be done in two insns. */
   if (arm_tune_xscale)
     arm_constant_limit = 2;
 
-  /* If optimizing for size, bump the number of instructions that we
-     are prepared to conditionally execute (even on a StrongARM). 
-     Otherwise for the StrongARM, which has early execution of branches,
-     a sequence that is worth skipping is shorter.  */
-  if (optimize_size)
-    max_insns_skipped = 6;
-  else if (arm_is_strong)
+  /* StrongARM has early execution of branches, so a sequence that
+     is worth skipping is shorter.  */
+  if (arm_is_strong)
     max_insns_skipped = 3;
+
+  if (optimize_size)
+    {
+      /* If optimizing for space, we let the compiler synthesize constants
+         with up to 2 insns, which uses the same space as a load from memory.
+         This gives the opportunity to take even less space when different
+         offsets can be factorized into multiple pre-indexed loads or stores. */
+      arm_constant_limit = 2;
+
+      /* If optimizing for size, bump the number of instructions that we
+         are prepared to conditionally execute (even on a StrongARM). */ 
+      max_insns_skipped = 6;
+    }
 
   /* Register global variables with the garbage collector.  */
   arm_add_gc_roots ();



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]