I don't understand why it is necessary to bother "VF". "VF” should not be changed since intrinsic stuff is quite stable and any unreasonable changes are unacceptable.
>> What are the many instructions that are valid in TARGET_ZVFHMIN? vle/vse/vluxei/vloxei/vsuxei/vsoxei/vlse/vsse. juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-06-22 21:22 To: 钟居哲; gcc-patches; palmer; kito.cheng; pan2.li; Jeff Law CC: rdapp.gcc Subject: Re: [PATCH] RISC-V: Split VF iterators for Zvfh(min). > You change "VF" constraint as "TARGET_ZVFH" which is incorrect since > we a lot of instructions are valid in "TARGET_ZVFHMIN" in vector.md > but you disabled them in this patch. You disabled them unexpectedly. Yes that was kind of the point :) IMHO all the :VF insns are actually only valid in a TARGET_ZVFH setting with the exception of pred_broadcast which I changed to VF_ZVFHMIN (vfmv.v.f and vfmv.s.f will be "masked out" by the "enabled" attribute). Now I'm not saying I might have missed/mixed up some insns in this patch but e.g. the binops/unops shouldn't be enabled (and their alternatives are already disabled as of now). What are the many instructions that are valid in TARGET_ZVFHMIN? Regards Robin
