RFC: MIPS paired single vector support

[Richard Sandiford]

Might as well comment on both pieces of work in one go...

Nigel Stephens <nigel@mips.com> writes:
> 1.4 Builtin Functions

FWIW, I like the __builtin_mips_insn() names (where "insn" is the full
mnemonic with "."s converted to "_"s).  They're very consistent, and
unlikely to cause conflicts with later target-independent builtins.
If anyone objects to the verbosity, they can always write a header
file with appropriate defines.

But I'd really like to avoid things like:

> 1.4.10 Conditional Move Based on Floating Point Comparison
>        (C.*.PS, MOVT.PS/MOVF.PS)
> v2sf __builtin_mips_mov*_c_*_ps (v2sf, v2sf, v2sf, v2sf);

and "just" have a c_*_ps builtin.  I know these compound functions are
due to the paired-cr difficulty that you & Jim were talking about, but
I'd still rather not give up on it unless there's a specific reason why
it can't be done.

Not objecting, but what was the reason for adding -mpaired-single?
Is there really any reason why you wouldn't want paired-single insns
when compiling for an ISA that supports them?

BTW, glad to hear you've got the copyright assignment sorted out ;)


WRT Jim's patch: it looks OK at first glance, but:

  - I'm not sure the paired-single stuff should depend on TARGET_DOUBLE_FLOAT,
    That's more for double-precision support.

    You also check TARGET_FLOAT64, and I think the only reason why you
    might ever have TARGET_FLOAT64 && !TARGET_DOUBLE_FLOAT is if you
    have paired-single operations but no double operations.

  - I'd prefer a macro like:

       #define TARGET_PAIRED_SINGLE \
         (ISA_HAS_PAIRED_SINGLE && TARGET_HARD_FLOAT && TARGET_FLOAT64)

    in order to avoid duplicating the full condition everywhere.
    (I know you're only following existing practice here, but that's
    not necessarily the best thing when it comes to the MIPS port ;)

  - Shouldn't VECTOR_MODE_SUPPORT_P depend on the suggested
    TARGET_PAIRED_SINGLE rather than ISA_PAIRED_SINGLE?

  - I'd rather keep MIPS32R2 out of ISA_HAS_PAIRED_SINGLE until such
    time as we support TARGET_FLOAT64 && !TARGET_64BIT.

  - Are there any cases where you take advantage of the new V2SF mode
    attribute?  It looks like you just treat it in the same way as
    SF in places where it matters.  I imagine that'll be the case for
    other processors besides SB-1 as well, so maybe just using SFmode
    would be better, at least until we know that the distinction is
    needed.

  - Just to warn you that the ABI part of the patch conflicts with the
    patch for PR 16446.  If David's testing goes OK, I'm hoping to apply
    an update of that patch soon.  (The "update" is to change
    "== MAX_MAX_ARGS_IN_REGISTERS - 1" to ">=".)

Richard