[llvm] [RISCV] Remove`riscv.segN.load/store` in favor of their mask variants (PR #137045)

[Min-Yih Hsu via llvm-commits]

mshockwave wrote:

> > Note that riscv.segN.load/store.mask does not take pointer type (i.e. address space) as part of its overloading type signature, because RISC-V doesn't really use address spaces other than the default one.
> 
> When user code does use address spaces expecting the backend to ignore them, the fact that the masked intrinsics don't take pointer type now causes LLVM to assert when these are used unchecked (`` /home/harald/llvm-project/main/llvm/lib/IR/Instructions.cpp:754: void llvm::CallInst::init(llvm::FunctionType*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, llvm::ArrayRef<llvm::OperandBundleDefT<llvm::Value*> >, const llvm::Twine&): Assertion `(i >= FTy->getNumParams() || FTy->getParamType(i) == Args[i]->getType()) && "Calling a function with a bad signature!"' failed. ``). We cannot just assume that LLVM IR does not use address spaces, even if the backend does not care about them.

A good point, thanks for bringing this up!

> Back when I had submitted #91573 for a similar issue elsewhere, it had been said that we should update the intrinsics to take pointer type. Should we include a similar check here to skip non-default address spaces so that we don't crash, or should we take this as a good opportunity to add proper support for non-default address spaces?

I think there is a subtle difference between these two approaches: if users want to use the address space to do some "creative" stuffs that differ from the traditional sense of address space -- for instance, an annotation of coarse-grained capabilities -- then rejecting any address spaces other than the default one might lose some optimization opportunities. However, this won't be a problem if we ignore the address space by overloading pointer types in these intrinsics.

Personally I'm more inclined to reject non-default address spaces until there is a strong use case of supporting these address spaces. Not only because updating intrinsics and test cases might create a big code churn, as you pointed out, but also due to the fact that new features should be driven by demand rather than the other way around.

https://github.com/llvm/llvm-project/pull/137045