[mlir] Add classes to define new TypeIDs at runtime

[math-fehr]

Summary

TypeIDAllocator enables the allocation of new TypeIDs at runtime,
that are unique during the lifetime of the allocator.

NonMovableTypeIDOwner is a class used to define a new TypeID for each instance
of a class, using the instance address. This class cannot be copied or moved.

[bondhugula]

mlir/include/mlir/Support/TypeID.h

151

Nit: Since this is a TypeID allocator, you can name this allocate().

[rriddle]

mlir/include/mlir/IR/MLIRContext.h

147 ↗

(On Diff #353000)

Why does this need to be in the context? Couldn't the TypeID allocator be owned by whatever is using it? (e.g. the extensible dialect)

mlir/include/mlir/Support/TypeID.h

145

159

Why not use a BumpPtrAllocator here instead? It doesn't look like you need the individual instances.

[math-fehr]

Rename function, and use bump pointer allocator

[math-fehr]

Fix spelling error

[math-fehr]

This comment was removed by math-fehr.

mlir/include/mlir/IR/MLIRContext.h

147 ↗

(On Diff #353000)

We could put a TypeID allocator in the extensible dialects for the operations and types TypeID.
However, we would still have a problem with the Dialects and Traits defined at runtime, since they need to be stored in the MLIRContext (I do not have a better solution for that currently).

There is however another solution we could consider, which is to create a class (let's call it DynamicObject) which hold a TypeID, as well as the storage if necessary. If we would make the DynamicOp/DynamicDialects/... all child classes of this DynamicObject, we wouldn't need any TypeIDAllocator, beside for the operations (since they are stored entirely in the AbstractOperation class). Also, alternatively, we could use the address of the DynamicTypeDefinition for the TypeID (which would give us for free a lookup for the type given the TypeID).

[math-fehr]

Sorry, I think I added myself as a reviewer by mistake.

[math-fehr]

@rriddle, a gentle ping on this.
What do you think would be the best course of action here?
As I said in a previous comment, I could either keep the TypeIDAllocator in the MLIRContext, or move it to the ExtensibleDialect and having the "dynamic" objects owning their TypeIDs.

[math-fehr]

Hey @rriddle, a gentle ping on this ^

[rriddle]

mlir/include/mlir/IR/MLIRContext.h

147 ↗

(On Diff #353000)

I really like the idea of a DynamicObject of some kind, which could internally use its own address for the TypeID? I think something like this could be placed directly within TypeID.h. The name would need to be different of course.

[math-fehr]

Add NonMovableTypeIDOwner, and remove TypeIDAllocator from MLIRContext

[math-fehr]

Was this class what you add in mind? I can also define another class that owns its TypeID by having a pointer to some place in memory if this can be useful.

[rriddle]

LGTM, nice.

mlir/include/mlir/Support/TypeID.h

161

I'm not sure we need the NonMovable in the name of the type. Something like SelfOwningTypeID or something that better convey the usage of this class seems better.

163

?

169

If you end up removing Owner from the name, this could also just be an implicit conversion to TypeID.

[trilorez]

Hi, I was wondering about the status of this patch. I'd be interested in using it in my project.

[math-fehr]

Address comments, and rename class to SelfOwningTypeID

[math-fehr]

Sorry, I just applied the last changes, and this should be ready to be committed I believe!
@rriddle, could you commit it for me if this is good for you? I do not have commit rights.

[rriddle]

In D104534#3267813, @math-fehr wrote:

Sorry, I just applied the last changes, and this should be ready to be committed I believe!
@rriddle, could you commit it for me if this is good for you? I do not have commit rights.

Yeah, I'll land tomorrow.

[rriddle]

In D104534#3289397, @rriddle wrote:

In D104534#3267813, @math-fehr wrote:

Sorry, I just applied the last changes, and this should be ready to be committed I believe!
@rriddle, could you commit it for me if this is good for you? I do not have commit rights.

Yeah, I'll land tomorrow.

Woah, missed this. Can you reupload with arc? Alternatively, I need an email to land with.

[math-fehr]

No problem!

Could you land it with [e-mail] ? My arc is currently broken :/

mlir/include/mlir/Support/TypeID.h

 //===----------------------------------------------------------------------===//
 
 #ifndef MLIR_SUPPORT_TYPEID_H
 #define MLIR_SUPPORT_TYPEID_H
 
 #include "mlir/Support/LLVM.h"
 #include "llvm/ADT/DenseMapInfo.h"
 #include "llvm/ADT/Hashing.h"
+#include "llvm/Support/Allocator.h"
 #include "llvm/Support/PointerLikeTypeTraits.h"
 
 namespace mlir {
 
 namespace detail {
 struct TypeIDExported;
 } // namespace detail
 

 private:
   TypeID(const Storage *storage) : storage(storage) {}
 
   /// The storage of this type info object.
   const Storage *storage;
 
   // See TypeIDExported below for an explanation of the trampoline behavior.
   friend struct detail::TypeIDExported;
+
+  friend class TypeIDAllocator;
 };
 
 /// Enable hashing TypeID.
 inline ::llvm::hash_code hash_value(TypeID id) {
   return DenseMapInfo<const TypeID::Storage *>::getHashValue(id.storage);
 }
 
 namespace detail {

 TypeID TypeID::get() {
   return detail::TypeIDExported::get<T>();
 }
 template <template <typename> class Trait>
 TypeID TypeID::get() {
   return detail::TypeIDExported::get<Trait>();
 }
 
+/// This class provides a way to define new TypeIDs at runtime.
+/// When the allocator is destructed, all allocated TypeIDs become invalid and
+/// therefore should not be used.
+class TypeIDAllocator {
+public:
+  /// Allocate a new TypeID, that is ensured to be unique for the lifetime
+  /// of the TypeIDAllocator.
+  TypeID allocate() { return TypeID(ids.Allocate()); }
+
+private:
+  /// The TypeIDs allocated are the addresses of the different storages.
+  /// Keeping those in memory ensure uniqueness of the TypeIDs.
+  llvm::SpecificBumpPtrAllocator<TypeID::Storage> ids;
+};
+
+/// Defines a TypeID for each instance of this class by using a pointer to the
+/// instance. Thus, the copy and move constructor are deleted.
+class SelfOwningTypeID {
+public:
+  SelfOwningTypeID() = default;
+  SelfOwningTypeID(const SelfOwningTypeID &) = delete;
+  SelfOwningTypeID &operator=(const SelfOwningTypeID &) = delete;
+  SelfOwningTypeID(SelfOwningTypeID &&) = delete;
+  SelfOwningTypeID &operator=(SelfOwningTypeID &&) = delete;
+
+  TypeID getTypeID() const { return TypeID::getFromOpaquePointer(this); }
+};
+
 } // namespace mlir
 
 // Declare/define an explicit specialization for TypeID: this forces the
 // compiler to emit a strong definition for a class and controls which
 // translation unit and shared object will actually have it.
 // This can be useful to turn to a link-time failure what would be in other
 // circumstances a hard-to-catch runtime bug when a TypeID is hidden in two
 // different shared libraries and instances of the same class only gets the same