[PATCH] D135202: [IR] Add a target extension type to LLVM.

[Joshua Cranmer via Phabricator via llvm-commits]

jcranmer-intel added a comment.

In D135202#4022488 <https://reviews.llvm.org/D135202#4022488>, @zixuan-wu wrote:

> hi, @jcranmer-intel , could you please propose a backend demo revision to demonstrate how to use targetext type of backend?

I don't have an example backend that goes through GlobalISel or SelectionDAG yet; I've been focusing my effort on the production SPIR-V backend which translates to SPIR-V straight from LLVM IR.

There may need to be some additional work to map these types to appropriate MVT types in the codegen phases, but my knowledge of codegen infrastructure is somewhat shaky, and this is highly dependent on how different backends wish to translate these types.

In D135202#4026617 <https://reviews.llvm.org/D135202#4026617>, @hctim wrote:

> Hey, looks like this patch may have introduced a memory leak, as reported below by ASan.

That is a good catch. I have a fix for this, I think, in https://reviews.llvm.org/D141083 -- can you test it out?



================
Comment at: llvm/lib/IR/Type.cpp:841
+struct TargetTypeInfo {
+  Type *LayoutType;
+  uint64_t Properties;
----------------
zixuan-wu wrote:
> Can the LayoutType be struct type, or scalable vector type?
Yes.


================
Comment at: llvm/lib/IR/Type.cpp:854
+  if (Name.startswith("spirv.")) {
+    return TargetTypeInfo(Type::getInt8PtrTy(C, 0), TargetExtType::HasZeroInit,
+                          TargetExtType::CanBeGlobal);
----------------
zixuan-wu wrote:
> Is there anymore better code structure to separate target-specific code to get TargetTypeInfo such as individual hook?
In principle, it is possible to provide target hooks that could let individual targets define their own TargetTypeInfo tables. However, there is a bit of a layering issue: the information needed is too verbose to stuff into a datalayout string, and the existing target hooks aren't in a place where they can make it to DataLayout (who needs to know the size) or Verifier (for the other properties). Something new would have to be added, and it's not clear that it provides significant advantages over a hardcoded list for now.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135202/new/

https://reviews.llvm.org/D135202