[Bug target/83387] PowerPC64: Infinite loops in do_reload() with -msoft-float

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387

--- Comment #9 from Peter Bergner <bergner at gcc dot gnu.org> ---
...and the parallel with the  FP reg use (33 and 34) come from:

expand_call():
  valreg = hard_function_value (build_pointer_type (rettype),
                                fndecl, NULL, (pass == 0));

  hard_function_value():
    val = targetm.calls.function_value (valtype, func ? func : fntype,
outgoing);

    rs6000_function_value():

  /* The ELFv2 ABI returns homogeneous VFP aggregates in registers.  */
  if (rs6000_discover_homogeneous_aggregate (mode, valtype, &elt_mode,
&n_elts))
    {
      int first_reg, n_regs;

      if (SCALAR_FLOAT_MODE_NOT_VECTOR_P (elt_mode))
        {
          /* _Decimal128 must use even/odd register pairs.  */
          first_reg = (elt_mode == TDmode) ? FP_ARG_RETURN + 1 : FP_ARG_RETURN;
          n_regs = (GET_MODE_SIZE (elt_mode) + 7) >> 3;
        }
      else
        {
          first_reg = ALTIVEC_ARG_RETURN;
          n_regs = 1;
        }

      return rs6000_parallel_return (mode, n_elts, elt_mode, first_reg,
n_regs);
    }

Here, you can see that on ELFv2, we always assume HW FP regs are avialable,
because we're forcing usage of HW FP registers (FP_ARG_RETURN, ie, f1, aka reg
33).  I'm afraid that are going to be a *LOT* of these assumptions builtin into
the backend and tracking them all down and fixing them is not going to be easy.
 That's why I asked earlier, if you really really need to disable HW FP for
your builds.  If you do, then good luck to you finding them all.