You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the original SPIR-V CodeGen, llvm::TargetExtType is employed for OpenCL built-in types like pipe and image, which encapsulate certain type-specific parameters. This design choice is discussed in the RFC Adding opaque types to LLVM IR.
Opaque types are a new kind of fundamental LLVM type. The C++ API for this type, at least as far as type creation looks, would be as follows:
class OpaqueType : public Type {
public:
static void get(LLVMContext &Ctx, StringRef Name);
static void get(LLVMContext &Ctx, StringRef Name,
ArrayRef<Type *> Types, ArrayRef<unsigned> Parameters);
};
The use of TargetExtType, or the previously known OpaqueType, is quite limited within LLVM until now, primarily involving OpenCL/SPIR-V and Arm's scalable vector extension. It's important to consider the appropriate level of abstraction for these types collectively, as the LLVM community has done.
From LLVM's standpoint, the goal is to maintain a clean type system. These target-specific types function similarly to pointers or unique handles, with the main purpose being to distinguish them from standard types like word-sized integers. This perspective is also relevant for ClangIR. However, we should proceed with caution when introducing an LLVM equivalent in ClangIR.
The text was updated successfully, but these errors were encountered:
In the original SPIR-V CodeGen,
llvm::TargetExtType
is employed for OpenCL built-in types likepipe
andimage
, which encapsulate certain type-specific parameters. This design choice is discussed in the RFC Adding opaque types to LLVM IR.The use of
TargetExtType
, or the previously knownOpaqueType
, is quite limited within LLVM until now, primarily involving OpenCL/SPIR-V and Arm's scalable vector extension. It's important to consider the appropriate level of abstraction for these types collectively, as the LLVM community has done.From LLVM's standpoint, the goal is to maintain a clean type system. These target-specific types function similarly to pointers or unique handles, with the main purpose being to distinguish them from standard types like word-sized integers. This perspective is also relevant for ClangIR. However, we should proceed with caution when introducing an LLVM equivalent in ClangIR.
The text was updated successfully, but these errors were encountered: