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]

Re: [Patch, MIPS] Enable fp-contract on MIPS and update -mfused-madd


"Maciej W. Rozycki" <macro@linux-mips.org> writes:
> On Wed, 17 Jun 2015, Steve Ellcey wrote:
>> Well, I don't mind removing the HONOR_NAN checks from the MIPS code in
>> my patch but I am not sure I can do a patch to remove it from the shared
>> code.  I see about 80 HONOR_NAN checks in the shared code and I am not
>> sure which ones can and cannot be removed.
>
>  FAOD I meant to remove the checks globally throughout MIPS target code 
> only.

FWIW, to be specific, I think we're talking about every check except
the last two in mips.md:

(define_insn "abs<mode>2"
  [(set (match_operand:ANYF 0 "register_operand" "=f")
	(abs:ANYF (match_operand:ANYF 1 "register_operand" "f")))]
  "mips_abs == MIPS_IEEE_754_2008 || !HONOR_NANS (<MODE>mode)"
  "abs.<fmt>\t%0,%1"
  [(set_attr "type" "fabs")
   (set_attr "mode" "<UNITMODE>")])

(define_insn "neg<mode>2"
  [(set (match_operand:ANYF 0 "register_operand" "=f")
	(neg:ANYF (match_operand:ANYF 1 "register_operand" "f")))]
  "mips_abs == MIPS_IEEE_754_2008 || !HONOR_NANS (<MODE>mode)"
  "neg.<fmt>\t%0,%1"
  [(set_attr "type" "fneg")
   (set_attr "mode" "<UNITMODE>")])

and the one mips-ps-3d.md:

(define_expand "mips_abs_ps"
  [(set (match_operand:V2SF 0 "register_operand")
	(unspec:V2SF [(match_operand:V2SF 1 "register_operand")]
		     UNSPEC_ABS_PS))]
  "TARGET_HARD_FLOAT && TARGET_PAIRED_SINGLE_FLOAT"
{
  /* If we can ignore NaNs, this operation is equivalent to the
     rtl ABS code.  */
  if (!HONOR_NANS (V2SFmode))
    {
      emit_insn (gen_absv2sf2 (operands[0], operands[1]));
      DONE;
    }
})

In particular, the two checks in mips.c should go.

But like I say, please do add a comment above the unfused patterns to say
why we can match NEG here without the HONOR_NANS test.  It's going to be
far from obvious to anyone who hasn't read this thread.

It's also worth pointing out (although it's probably obvious) that this is
effectively going to be a no-op change.  We'd never have a NEG to combine
if we were honouring NANs and using the legacy pre-2008 mode.  We should
still be accurate though.  Especially when it's also less code :-)

Thanks,
Richard


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