This adds value types for representing capability types, enabling their use in instruction selection and other parts of the backend. These types are distinguished from each other only by size. This is sufficient, at least today, because no existing CHERI configuration supports multiple capability sizes simultaneously. Hybrid configurations supporting intermixed integral pointers and capabilities do exist, and are one of the reasons why these value types are needed beyond existing integral types. Co-authored-by: David Chisnall <theraven@theravensnest.org> Co-authored-by: Jessica Clarke <jrtc27@jrtc27.com>
This rewrites the fold from #129756 to apply to all types, including stores of i8s. This required adding a new `aarch64mfp8` MVT to represent FPR8 types on AArch64, which can be used to extract and store 8-bit values using b sub-registers. Follow on from: #129756 Closes: #131793
The old hack of returning v5/v6i32 for the fat and strided buffer pointers was causing issuse during vectorization queries that expected to be able to construct a VectorType from the return value of `MVT getPointerType()`. On example is in the test attached to this PR, which used to crash. Now, we define the custom MVT entries, the 160-bit amdgpuBufferFatPointer and 192-bit amdgpuBufferStridedPointer, which are used to represent ptr addrspace(7) and ptr addrspace(9) respectively. Neither of these types will be present at the time of lowering to a SelectionDAG or other MIR - MVT::amdgpuBufferFatPointer is eliminated by the LowerBufferFatPointers pass and amdgpu::bufferStridedPointer is not currently used outside of the SPIR-V translator (which does its own lowering). An alternative solution would be to add MVT::i160 and MVT::i192. We elect not to do this now as it would require changes to unrelated code and runs the risk of breaking any SelectionDAG code that assumes that the MVT series are all powers of two (and so can be split apart and merged back together) in ways that wouldn't be obvious if someone tried to use MVT::i160 in codegen. If i160 is added at some future point, these custom types can be retired.
Vector tuple is basically multiple grouped vector, so its size is also determined by vscale, we need not to model it as a vector type but its size need to be scalable.
Summary: This patch handles the types(MVT) in `selectionDAG` for RISCV vector tuples. As described in previous patch handling llvm types, the MVTs also have 32 variants: ``` riscv_nxv1i8x2, riscv_nxv1i8x3, riscv_nxv1i8x4, riscv_nxv1i8x5, riscv_nxv1i8x6, riscv_nxv1i8x7, riscv_nxv1i8x8, riscv_nxv2i8x2, riscv_nxv2i8x3, riscv_nxv2i8x4, riscv_nxv2i8x5, riscv_nxv2i8x6, riscv_nxv2i8x7, riscv_nxv2i8x8, riscv_nxv4i8x2, riscv_nxv4i8x3, riscv_nxv4i8x4, riscv_nxv4i8x5, riscv_nxv4i8x6, riscv_nxv4i8x7, riscv_nxv4i8x8, riscv_nxv8i8x2, riscv_nxv8i8x3, riscv_nxv8i8x4, riscv_nxv8i8x5, riscv_nxv8i8x6, riscv_nxv8i8x7, riscv_nxv8i8x8, riscv_nxv16i8x2, riscv_nxv16i8x3, riscv_nxv16i8x4, riscv_nxv32i8x2. ``` Detail: An intuitive way to model vector tuple type is using nested scalable vector, e.g. `nElts=NF, EltTy=nxv2i32`. However it's not compatible to what we've done to handle scalable vector in TargetLowering, so it would need more effort to change the code to handle this concept. Another approach is encoding the `MinNumElts` info in `sz` of `MVT`, e.g. `nElts=NF, sz=(NF*MinNumElts*8)`, this makes it much easier to handle and changes less code. This patch adopts the latter approach. Stacked on https://github.com/llvm/llvm-project/pull/97992
This will be used to replace SelectionDAG::EVTToAPFloatSemantics A similar method exists in IR's Type class.
It is now translated to `<1 x i64>`, which allows the removal of a bunch of special casing. This _incompatibly_ changes the ABI of any LLVM IR function with `x86_mmx` arguments or returns: instead of passing in mmx registers, they will now be passed via integer registers. However, the real-world incompatibility caused by this is expected to be minimal, because Clang never uses the x86_mmx type -- it lowers `__m64` to either `<1 x i64>` or `double`, depending on ABI. This change does _not_ eliminate the SelectionDAG `MVT::x86mmx` type. That type simply no longer corresponds to an IR type, and is used only by MMX intrinsics and inline-asm operands. Because SelectionDAGBuilder only knows how to generate the operands/results of intrinsics based on the IR type, it thus now generates the intrinsics with the type MVT::v1i64, instead of MVT::x86mmx. We need to fix this before the DAG LegalizeTypes, and thus have the X86 backend fix them up in DAGCombine. (This may be a short-lived hack, if all the MMX intrinsics can be removed in upcoming changes.) Works towards issue #98272.
Most of MVT has simple mapping to the LLVM type, so it would be nice to auto generate that from ValueTypes.td, that could reduce the effort when we adding new MVT, especially new vector MVT with different size.
This adds (back) the exnref type restored in the new EH proposal adopted in Oct 2023 CG meeting: https://github.com/WebAssembly/exception-handling/blob/main/proposals/exception-handling/Exceptions.md:x
There is the expectation throughout CodeGen that, for types representing "real" values, the MVT or EVT is self-contained. However, MVT::iPTR is challenging, because it has no address space, and even if it did, there often is no DataLayout immediately accessible to determine what actually is the underlying type. Historically it was documented as being TableGen-only, but that was lost in 631bfdbee5b45eda9f99dff6a716d63c5698e4bd's conversion to using the generated defines. Let's preserve that intent by not allowing it to originate through accidental calls to get(E)VT with a PointerType. If you need to support that, be sure to use something like TargetLowering's getValueType, which takes a DataLayout and can map pointers to their concrete MVTs. Whilst here, reintroduce documentation about these value types being TableGen-only.