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]

[PATCH,rs6000] fix logic error with rs6000_gen_cell_microcode


rs6000_override_options contains this interesting bit of logic:

  /* Disable Cell microcode if we are optimizing for the Cell
     and not optimizing for size.  */
  if (rs6000_gen_cell_microcode == -1)
    rs6000_gen_cell_microcode = !(rs6000_cpu == PROCESSOR_CELL
                                  && !optimize_size);

where the consequent is saying (after applying simplification):

    rs6000_gen_cell_microcode = (rs6000_cpu != PROCESSOR_CELL
                                 || optimize_size);

and that turns out to make rs6000_gen_cell_microcode true for the vast
majority of PPC gcc invocations.  Hm, that's odd.  Why would we want to
generate Cell microcode on non-Cell machines?  Well,
rs6000_gen_cell_microcode means "it's OK to generate instructions that
would be microcoded on Cell."  Using it in define_insn conditions that
way is just fine.

Unfortunately, the next bit of code in rs6000_override_options is:

  /* If we are optimizing big endian systems for space, use the load/store
     multiple and string instructions unless we are not generating
     Cell microcode.  */
  if (BYTES_BIG_ENDIAN && optimize_size && !rs6000_gen_cell_microcode)
    target_flags |= ~target_flags_explicit & (MASK_MULTIPLE | MASK_STRING);

Since rs6000_gen_cell_microcode is true in almost all cases, this
condition disables use of load/store-multiple and string instructions if
you're optimizing for size on a processor other than Cell.

I don't think this is what we want.  (Notice that the comment
contradicts the code.)  Doing this is a regression from previous
versions of GCC that didn't have the check--if you have a function that
only needs a few registers saved/restored, GCC will now use lw/stw
instead of lmw/stmw if you are optimizing for size.

The patch below, therefore, inverts the check on
rs6000_gen_cell_microcode and fixes the explanatory comment.  I think
this is what we really want; the information I've been able to find
(http://cellperformance.beyond3d.com/articles/2006/04/avoiding-microcoded-instructions-on-the-ppu.html)
indicates that load/store multiple and string instructions on Cell are
microcoded.

Testing on powerpc-linux-gnu.  OK to commit?

-Nathan

	* config/rs6000/rs6000.c (rs6000_override_options): Invert check
	for rs6000_gen_cell_microcode.

Index: rs6000.c
===================================================================
--- rs6000.c	(revision 155110)
+++ rs6000.c	(working copy)
@@ -2378,10 +2378,10 @@ rs6000_override_options (const char *def
     rs6000_gen_cell_microcode = !(rs6000_cpu == PROCESSOR_CELL
                                   && !optimize_size);
 
-  /* If we are optimizing big endian systems for space, use the load/store
-     multiple and string instructions unless we are not generating
-     Cell microcode.  */
-  if (BYTES_BIG_ENDIAN && optimize_size && !rs6000_gen_cell_microcode)
+  /* If we are optimizing big endian systems for space and it's OK to
+     use instructions that would be microcoded on the Cell, use the
+     load/store multiple and string instructions.  */
+  if (BYTES_BIG_ENDIAN && optimize_size && rs6000_gen_cell_microcode)
     target_flags |= ~target_flags_explicit & (MASK_MULTIPLE | MASK_STRING);
 
   /* Don't allow -mmultiple or -mstring on little endian systems


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