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]

PPC aborts



I'm getting a ton of compiler aborts building lapack on a ppc linux machine.

In a nutshell reload wants to reload something like this into an SFmode GPR:

(const_double:SF (mem/u:SF (symbol_ref/u:SI ("*.LC2")) 0) 0 [0x0] 1072693248 
[0x3ff00000] [1])


We end up calling movsf with the SFmode GPR and the CONST_DOUBLE.

The movsf expander does something like this:

  if (CONSTANT_P (operands[1]) && TARGET_HARD_FLOAT)
    {
      operands[1] = force_const_mem (SFmode, operands[1]);
      if (! memory_address_p (SFmode, XEXP (operands[1], 0))
          && ! reload_in_progress)
        operands[1] = change_address (operands[1], SFmode,
                                      XEXP (operands[1], 0));
    }

That turns operands[1] into (mem/u:SF (symbol_ref/u:SI ("*.LC2")).  Since
reload is running we never call change_address and end up generating this
insn:

(insn 481 385 97 (set (reg:SF 0 r0)
        (mem/u:SF (symbol_ref/u:SI ("*.LC2")) 0)) -1 (nil)
    (nil))

Which does not match any known instruction in rs6000.md.


It was never necessary to force this constant into memory anyway since it
is an "easy" FP constant and can be handled directly by the movsf patterns.

Looking at the movdf expander it looks something like this which confirms
my suspicion that we need not flush this constant into memory:

  if (CONSTANT_P (operands[1]) && ! easy_fp_constant (operands[1], DFmode))
    {
      operands[1] = force_const_mem (DFmode, operands[1]);
      if (! memory_address_p (DFmode, XEXP (operands[1], 0))
          && ! reload_in_progress)
        operands[1] = change_address (operands[1], DFmode,
                                      XEXP (operands[1], 0));
    }

Note how it does not force the constant into memory if it is an easy constant.
I believe the movsf code should operate in a similar manner.

I've confirmed that adding the !easy_fp_constant check to the movsf expander
allows lapack to build (though it still gets test failures).  If we want to
be extra careful we could make the movsf test something like:

 (CONSTANT_P (opeands[1]
  && TARGET_HARD_FLOAT
  && reload_in_progress
  && GPR_REG_P (operands[0])
  && easy_fp_constant (operands[1], SFmode))

But I doubt that is necessary.

On a related note (for the mainline tree) we may want to tune
PREFERRED_RELOAD_CLASS to not force easy constants into memory when they
need to be reloaded.  Such a change does not fix this bug, but does reduce the
amount of reloads created when this situation occurs by avoiding useless
address reloads.


Anyway, here's the proposed fix to the movsf expander:

	* rs6000.md (movsf): Do not force easy FP constants into memory.

Index: rs6000.md
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/config/rs6000/rs6000.md,v
retrieving revision 1.55.4.7
diff -c -3 -p -r1.55.4.7 rs6000.md
*** rs6000.md	1999/07/02 00:36:48	1.55.4.7
--- rs6000.md	1999/07/12 16:57:00
***************
*** 6145,6151 ****
        operands[1] = force_reg (SFmode, operands[1]);
      }
  
!   if (CONSTANT_P (operands[1]) && TARGET_HARD_FLOAT)
      {
        operands[1] = force_const_mem (SFmode, operands[1]);
        if (! memory_address_p (SFmode, XEXP (operands[1], 0))
--- 6145,6152 ----
        operands[1] = force_reg (SFmode, operands[1]);
      }
  
!   if (CONSTANT_P (operands[1]) && TARGET_HARD_FLOAT
!       && ! easy_fp_constant (operands[1], SFmode))
      {
        operands[1] = force_const_mem (SFmode, operands[1]);
        if (! memory_address_p (SFmode, XEXP (operands[1], 0))



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