[llvm-dev] Creating unique Type objects

Russell Wallace via llvm-dev llvm-dev at lists.llvm.org
Sat Oct 31 03:42:37 PDT 2015

Looking in more depth at the relevant code, it looks like it's possible to
say e.g.

StructType::create(Context, "?")

and a unique name like ?.1, ?.2 etc will be automatically generated, so
that seems to fit the bill.

On Fri, Oct 30, 2015 at 9:40 PM, Russell Wallace <russell.wallace at gmail.com>

> I need to somehow add some extra elements to the LLVM type system, create
> some types in addition to the ones already defined.
> I don't think it's possible to add extra elements to enum TypeID, and
> therefore not possible to create genuinely new kinds of types. However, it
> might suffice to create new type objects of an existing kind. There is a
> bit of a stumbling block because of the way the system is designed, so I
> can't just create arbitrary new objects:
> /// The instances of the Type class are immutable: once they are created,
> /// they are never changed.  Also note that only one instance of a
> particular
> /// type is ever created.  Thus seeing if two types are equal is a matter
> of
> /// doing a trivial pointer comparison. To enforce that no two equal
> instances
> /// are created, Type instances can only be created via static factory
> methods
> /// in class Type and in derived classes.  Once allocated, Types are never
> /// free'd.
> As far as I can see, the most promising candidate is StructType, because
> that allows a name to be supplied. I think two struct types with different
> names are considered different - only anonymous struct types get merged? So
> maybe the best thing to do is to come up with a namespace that doesn't
> correspond to valid C++ type names and so will not have been already used?
> If so, are there any existing namespace usages to watch out for? E.g.
> suppose I thought of using names beginning with * but it turns out these
> are already in use by the compiler for some purpose but I could use +
> instead - is there anything like that?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151031/b326ac8e/attachment.html>

More information about the llvm-dev mailing list