[Bug target/117344] Suboptimal use of movprfx in SVE intrinsics code due to hard register for return register or argument passing

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The way cond_addvnx4si_2 is written currently is:
;; Predicated integer operations, merging with the first input.
(define_insn "*cond_<optab><mode>_2"
  [(set (match_operand:SVE_I 0 "register_operand")
        (unspec:SVE_I
          [(match_operand:<VPRED> 1 "register_operand")
           (SVE_INT_BINARY:SVE_I
             (match_operand:SVE_I 2 "register_operand")
             (match_operand:SVE_I 3 "register_operand"))
           (match_dup 2)]
          UNSPEC_SEL))]
  "TARGET_SVE"
  {@ [ cons: =0 , 1   , 2 , 3 ; attrs: movprfx ]
     [ w        , Upl , 0 , w ; *              ] <sve_int_op>\t%0.<Vetype>,
%1/m, %0.<Vetype>, %3.<Vetype>
     [ ?&w      , Upl , w , w ; yes            ] movprfx\t%0,
%2\;<sve_int_op>\t%0.<Vetype>, %1/m, %0.<Vetype>, %3.<Vetype>
  }
)

That is the move is before the instruction.
I wonder if we could use a clobber/match_scratch instead and then split after
reload. Maybe I am thinking too much into this.