[Bug rtl-optimization/114766] ^ constraint modifier unexpectedly affects register class selection.

["tnfchris at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #2 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Vladimir Makarov from comment #1)
> (In reply to Tamar Christina from comment #0)
> > The documentation for ^ states:
>
> If it works for you, we could try to use the patch (although it needs some
> investigation how other targets uses the hint).  In any case, the
> documentation should be modified or made more clear depending on applying or
> not applying the patch.

Yeah, using the patch gives us the behavior we expected, we added a workaround
for now so we can investigate what other targets do in GCC 15.

But while looking at this we also got some unexpected behavior with using ?

For instance we have the pattern:

;; Equal width integer to fp conversion.
(define_insn "<optab><fcvt_target><GPF:mode>2"
  [(set (match_operand:GPF 0 "register_operand")
        (FLOATUORS:GPF (match_operand:<FCVT_TARGET> 1 "register_operand")))]
  "TARGET_FLOAT"
  {@ [ cons: =0 , 1  ; attrs: type             , arch  ]
     [ w        , w  ; neon_int_to_fp_<Vetype> , simd  ]
<su_optab>cvtf\t%<GPF:s>0, %<s>1
     [ w        , ?r ; f_cvti2f                , fp    ]
<su_optab>cvtf\t%<GPF:s>0, %<w1>1
  })

for modeling floating point conversions. We had expected ? to make the
alternative more expensive, but still possible.  However again during IRA the
entire register class is blocked:

    r103: preferred FP_REGS, alternative NO_REGS, allocno FP_REGS

I would have expected that the additional penalty should never make an
alternative impossible.
We thought maybe the move costs were an issue, but we tried with various big
and small numbers but it looks like the move costs have little to no effect. 
Since the original value in this case was in r:

      Choosing alt 0 in insn 7:  (0) =rk  (1) %rk  (2) I {*adddi3_aarch64}

I would have expected the cost for FP_REGS not to be 0, as there's a register
file move involved:

  r103 costs: W8_W11_REGS:2000 W12_W15_REGS:2000 TAILCALL_ADDR_REGS:2000
STUB_REGS:2000 GENERAL_REGS:2000 FP_LO8_REGS:0 FP_LO_REGS:0 FP_REGS:0
POINTER_AND_FP_REGS:7000 MEM:9000

In this particular pattern the ? isn't needed so we're removing it, but the
behavior is still unexpected.