[RISCV] Reject i1 vp.load/vp.store in cost model (remove LV-side workaround)

[Copilot]

Full-LTO RVV codegen could still carry vp.load/vp.store forms that are not representable for i1 element memory semantics on RISC-V, leading to backend failures. This change moves the handling to the RISC-V profitability/cost layer instead of guarding it in LoopVectorize transforms.

• Problem framing

  • i1 vp.load/vp.store should be considered non-viable for RISC-V lowering.
  • Prevent this through cost invalidation, not ad-hoc mutation suppression in LoopVectorize.

• Targeted code changes

  • RISC-V TTI cost model
    • Updated RISCVTargetTransformInfo.cpp to return InstructionCost::getInvalid() for i1 vector vp_load/vp_store in:
      • getIntrinsicInstrCost(...)
    • Kept vp.load/vp.store memory intrinsic handling routed through getMaskedMemoryOpCost(...), which already relies on masked-memory legality checks (isLegalMaskedLoadStore / isLegalElementTypeForRVV) that reject i1 element types.
  • LoopVectorize cleanup
    • Reverted the optimizeMaskToEVL i1 guard workaround in VPlanTransforms.cpp so the fix is centralized in target cost modeling.

• Regression coverage

  • Extended llvm/test/Analysis/CostModel/RISCV/vp-intrinsics.ll with i1 VP memory cases asserting invalid cost.
  • Removed the temporary LoopVectorize regression test added for the prior workaround approach.

[lukel97]

@copilot doesn't getMaskedMemoryOpCost already check for isLegalMaskedLoadStore, which in turn already checks for TLI->isLegalElementTypeForRVV ? Which should disallow i1.

[Copilot]

You're right — getMaskedMemoryOpCost already funnels illegal i1 through BaseT::getMemIntrinsicInstrCost, which makes vp.load/vp.store invalid. I removed the redundant mem-intrinsic-side i1 guard in 7c1ef91.

I kept the getIntrinsicInstrCost i1 check because getInstructionCost for intrinsic calls goes through that path directly.