Hi Lehua, thanks for fixing this. Looks like the same reason we have the separation of zvfh and zvfhmin for vector loads/stores.
> +;; Iterator for hardware-supported load/store floating-point modes. > +(define_mode_iterator ANYLSF [(SF "TARGET_HARD_FLOAT || TARGET_ZFINX") > + (DF "TARGET_DOUBLE_FLOAT || TARGET_ZDINX") > + (HF "TARGET_ZFHMIN || TARGET_ZHINX")]) > + I first thought we needed TARGET_ZFH here as well but it appears that TARGET_ZFH implies TARGET_ZFHMIN via riscv_implied_info. We're lacking that on the vector side and this should be addressed separately. You likely want TARGET_ZHINXMIN instead of ZHINX though? I mean the hardware support is obviously always there but the patterns should be available for the min extension already. Please double check as I haven't worked with that extension before. Our test coverage for the *inx extensions is honestly a bit sparse, maybe you would also want to add a testcase for a similar scenario? > -;; We can support ANYF loads into X register if there is no double support > +;; We can support ANYLSF loads into X register if there is no double support > ;; or if the target is 64-bit> -(define_insn "*local_pic_load<ANYF:mode>" > - [(set (match_operand:ANYF 0 "register_operand" "=f,*r") > - (mem:ANYF (match_operand 1 "absolute_symbolic_operand" ""))) > +(define_insn "*local_pic_load<ANYLSF:mode>" > + [(set (match_operand:ANYLSF 0 "register_operand" "=f,*r") > + (mem:ANYLSF (match_operand 1 "absolute_symbolic_operand" ""))) > (clobber (match_scratch:P 2 "=r,X"))] > "TARGET_HARD_FLOAT && USE_LOAD_ADDRESS_MACRO (operands[1]) > && (!TARGET_DOUBLE_FLOAT || TARGET_64BIT)" > "@ > - <ANYF:load>\t%0,%1,%2 > + <ANYLSF:load>\t%0,%1,%2 > <softload>\t%0,%1" > [(set (attr "length") (const_int 8))]) Unrelated to your patch - but from a quick glimpse here I didn't see why we require TARGET_HARD_FLOAT for the softload alternatives. Aren't zdinx, zfinx, zhinx a bit of a SOFT_FLOAT thing? Well probably just semantics... Apart from that LGTM. Regards Robin
