Names for structs are held on the Context, not the Module. Move getTypeByName from Module to Type taking a Context parameter.

[nicholas]

Summary

Creating a named struct requires only a Context and a name, but looking up a struct by name requires a Module. The method on Module merely accesses the LLVMContextImpl and no data from the module itself, so this patch moves getTypeByName to a static method on StructType that takes a Context and a name.

There's a small number of users of this function, they are all updated.

This updates the C API adding a new method LLVMGetTypeByName2, naming suggestions welcome. I considered LLVMGetTypeByNameInContext, but the LLVM*InContext pattern is used to differentiate between methods that work on the global context and those that don't, and that isn't the case here.

[jdoerfert]

I think the new location is reasonable, I don't know about our C API policy though. Two questions below.

llvm/include/llvm-c/Core.h

874

1. Should we use the deprecated attribute here?
2. We cannot use attribute((overrload)) can we?

[nickwasmer]

llvm/include/llvm-c/Core.h

874

1. There aren't any other uses of attribute deprecated, or any GNU-style attribute in the C API header files. At a guess, this might be for compatibility with non-GNU compilers.

2. We can't. It would change the symbol name of both of them, which would be an ABI break for the existing LLVMGetTypeByName.

[jdoerfert]

llvm/include/llvm-c/Core.h

874

1. Unclear if that is really a problem but OK.
2. Makes sense.

[nickwasmer]

Ping!

[nickwasmer]

Ping!

[nickwasmer]

Ping!

[nickwasmer]

Ping!

[nickwasmer]

Ping!

[CodaFi]

C API changes LGTM. My one request is to update the echo llvm-c-test to use the new API.

[jdoerfert]

LLVM changes LGTM.

[nicholas]

Use LLVMGetTypeByName2 in llvm-c-test echo test too.

[nicholas]

llvm/include/llvm-c/Core.h

631

clang-tidy readability-identifier-naming doesn't like 'LLVMGetTypeByName2'. Should I ignore this because it's standard style for the LLVM C API? Or what should I change it to?

[dexonsmith]

@nicholas, I missed this when it was reviewed, but seeing it now that you've landed it.

Can you help me understand if there's a deeper motivation than the one in the patch description? I ask because I would have envisioned eventually moving these "named" types to the module (i.e., keep the old API before your change, but change the implementation to make sense of it).

In particular, it would be nice if LLVMContext were restricted to types / values / metadata that are purely functional, and anything non-functional or open to interpretation is put on the Module.

• For values and metadata, this requires some significant work (I have some concrete ideas of how, but it seems quite tangential to this patch).
• For types, this could be done as a very simple follow-up to the opaque pointer work (@dblaikie @arsenm, not sure if you have thoughts). The Type class would be purely functional, and the struct names would move to a symbol table in each Module. The name is not inherent to the type, it's just a handle that some module wants to use to refer to it (the type itself can be shared between modules even if they disagree about what to call it).

One benefit of this hypothetical change is that we could change everything in LLVMContext to be immutable, potentially using lock-free data structures, etc.; I think that would open up some interesting possibilities.

[nicholas]

In D78793#2424013, @dexonsmith wrote:

@nicholas, I missed this when it was reviewed, but seeing it now that you've landed it.

Can you help me understand if there's a deeper motivation than the one in the patch description? I ask because I would have envisioned eventually moving these "named" types to the module (i.e., keep the old API before your change, but change the implementation to make sense of it).

My motivation really is only what's stated in the description, I was asked about this by an author of an LLVM wrapper for Rust, all the other APIs didn't need a Module and this one did. If I remember right, LLVM pre-3.0 used to work as you describe, at which point the current system where distinct names of structs imply distinct struct types was introduced leading to a major simplification / performance improvement in forward declarations and module linking. See the first bullet under "Internal API Changes" in https://releases.llvm.org/3.0/docs/ReleaseNotes.html . My justification for this patch is that it's just cleaning up this one spot that was missed way back in the 2.9 -> 3.0 cycle.

In particular, it would be nice if LLVMContext were restricted to types / values / metadata that are purely functional, and anything non-functional or open to interpretation is put on the Module.

• For values and metadata, this requires some significant work (I have some concrete ideas of how, but it seems quite tangential to this patch).
• For types, this could be done as a very simple follow-up to the opaque pointer work (@dblaikie @arsenm, not sure if you have thoughts). The Type class would be purely functional, and the struct names would move to a symbol table in each Module. The name is not inherent to the type, it's just a handle that some module wants to use to refer to it (the type itself can be shared between modules even if they disagree about what to call it).

I don't have much to add here, I'd simply recommend that you have a plan for dealing with the problems of type merging and refinement, structs whose members are pointers to that same struct (detect and reject creating a struct that holds itself as a member, %0 = type { \0 }), etc., before making the change.

I'm not familiar with the opaque pointer work and how it affects the types and context.

One benefit of this hypothetical change is that we could change everything in LLVMContext to be immutable, potentially using lock-free data structures, etc.; I think that would open up some interesting possibilities.

Offhand it's not clear to me that the LLVMContext becomes immutable? It still has to construct those pure-functional objects exactly once to ensure they're pointer-comparable, and that's a mutation? Perhaps you can do that without a lock, and that's close enough?

llvm/include/llvm-c/Core.h

631

clang-tidy readability-identifier-naming doesn't like 'LLVMGetTypeByName2'. Should I ignore this because it's standard style for the LLVM C API? Or what should I change it to?

It appears that this blocks buildbot due to the clang-tidy error. I'll try suppressing with NOLINT now, but it'd be nice if the automated checks were aware of the C API.

[dexonsmith]

In D78793#2424081, @nicholas wrote:

My justification for this patch is that it's just cleaning up this one spot that was missed way back in the 2.9 -> 3.0 cycle.

Fair enough, makes sense to me.

In particular, it would be nice if LLVMContext were restricted to types / values / metadata that are purely functional, and anything non-functional or open to interpretation is put on the Module.

• For values and metadata, this requires some significant work (I have some concrete ideas of how, but it seems quite tangential to this patch).
• For types, this could be done as a very simple follow-up to the opaque pointer work (@dblaikie @arsenm, not sure if you have thoughts). The Type class would be purely functional, and the struct names would move to a symbol table in each Module. The name is not inherent to the type, it's just a handle that some module wants to use to refer to it (the type itself can be shared between modules even if they disagree about what to call it).

I don't have much to add here, I'd simply recommend that you have a plan for dealing with the problems of type merging and refinement, structs whose members are pointers to that same struct (detect and reject creating a struct that holds itself as a member, %0 = type { \0 }), etc., before making the change.

I'm not familiar with the opaque pointer work and how it affects the types and context.

Yeah, that's exactly what's fixed by the opaque pointer work: it turns the type graph into a DAG. In your example, the type wasn't holding itself as a member (that's not possible), it was holding a pointer to itself as a member. Once pointers are opaque, then it's just holding a pointer, no cycles anymore.

One benefit of this hypothetical change is that we could change everything in LLVMContext to be immutable, potentially using lock-free data structures, etc.; I think that would open up some interesting possibilities.

Offhand it's not clear to me that the LLVMContext becomes immutable? It still has to construct those pure-functional objects exactly once to ensure they're pointer-comparable, and that's a mutation? Perhaps you can do that without a lock, and that's close enough?

Sorry, the objects held by the LLVMContext would be immutable; adding things to it could certainly race; but yeah, I think you can do that without a lock.

[nicholas]

In D78793#2424089, @dexonsmith wrote:

In D78793#2424081, @nicholas wrote:

! In D78793#2424013, @dexonsmith wrote:
In particular, it would be nice if LLVMContext were restricted to types / values / metadata that are purely functional, and anything non-functional or open to interpretation is put on the Module.

• For values and metadata, this requires some significant work (I have some concrete ideas of how, but it seems quite tangential to this patch).
• For types, this could be done as a very simple follow-up to the opaque pointer work (@dblaikie @arsenm, not sure if you have thoughts). The Type class would be purely functional, and the struct names would move to a symbol table in each Module. The name is not inherent to the type, it's just a handle that some module wants to use to refer to it (the type itself can be shared between modules even if they disagree about what to call it).

I don't have much to add here, I'd simply recommend that you have a plan for dealing with the problems of type merging and refinement, structs whose members are pointers to that same struct (detect and reject creating a struct that holds itself as a member, %0 = type { \0 }), etc., before making the change.

I'm not familiar with the opaque pointer work and how it affects the types and context.

Yeah, that's exactly what's fixed by the opaque pointer work: it turns the type graph into a DAG. In your example, the type wasn't holding itself as a member (that's not possible), it was holding a pointer to itself as a member. Once pointers are opaque, then it's just holding a pointer, no cycles anymore.

My initial reaction, that sounds like a great proposal!

Let me just think out loud, so to type. It's been a while since I last thought hard about the consequences of changes to the LLVM IR. Back In the 2.x series, LLVM had an OpaqueType that could take the place of any type. It was something that might be resolved as part of linking, and this made module linking pretty complicated as opaques got resolved (not to mention the rest of LLVM had to deal with opaques though really except it didn't really inside function bodies). OpaqueType was restricted to StructType by 2.9 in preparation for the 3.0 change. I want to make sure that having a replacement for OpaqueType that's restricted to pointers doesn't reintroduce most of the same problems. After all, pointers aren't the only type that have elements, why not array types? Array types can have struct elements and struct elements can have array types, so we'll still need to do a recursive check that a type is acyclic when constructed. That doesn't sound too bad, though I think it will have to be O(n^2) unless you can get it in the right data representation to use Tarjan's algorithm which will probably be tricky. It seems that the big difference here (vs. LLVM 2.9) is that we can have opaque pointers propagated through the whole IR including all the instructions that operate on pointers. Then when linking we match up types by structure and we never have to do any type refinement. The remaining challenge here is forward declared structs, we want those to match up by name during module linking, but is there any reason that can't be handled the same as current LLVM does it? Same name in two modules, if both have bodies one gets renamed, otherwise they're the same type. The name can then live on the module and not the context. StructType::setBody can still be used to take a struct from body-less to one with a body, though it still has to check for non-pointer recursive types on construction. Ah, but you never need to because the only way to get a legal cycle is through a pointer anyhow! So you still need empty-body structs for the forward declaration case (as in, the original C code used a forward-declared struct -- note that struct Foo; struct Foo f(); returning a non-pointer forward declared struct is valid in C) to handle module linking, but that's the only case, in all other cases you can pass in all fields at construction time. So you don't really need setBody at all, the module linker just has to change the types from the opaque one to the one with a body when moving the values.

Ok, I like this plan. Best of luck!

[dexonsmith]

In D78793#2424148, @nicholas wrote:

In D78793#2424089, @dexonsmith wrote:

In D78793#2424081, @nicholas wrote:

! In D78793#2424013, @dexonsmith wrote:
In particular, it would be nice if LLVMContext were restricted to types / values / metadata that are purely functional, and anything non-functional or open to interpretation is put on the Module.

• For values and metadata, this requires some significant work (I have some concrete ideas of how, but it seems quite tangential to this patch).
• For types, this could be done as a very simple follow-up to the opaque pointer work (@dblaikie @arsenm, not sure if you have thoughts). The Type class would be purely functional, and the struct names would move to a symbol table in each Module. The name is not inherent to the type, it's just a handle that some module wants to use to refer to it (the type itself can be shared between modules even if they disagree about what to call it).

I don't have much to add here, I'd simply recommend that you have a plan for dealing with the problems of type merging and refinement, structs whose members are pointers to that same struct (detect and reject creating a struct that holds itself as a member, %0 = type { \0 }), etc., before making the change.

I'm not familiar with the opaque pointer work and how it affects the types and context.

Yeah, that's exactly what's fixed by the opaque pointer work: it turns the type graph into a DAG. In your example, the type wasn't holding itself as a member (that's not possible), it was holding a pointer to itself as a member. Once pointers are opaque, then it's just holding a pointer, no cycles anymore.

My initial reaction, that sounds like a great proposal!

Let me just think out loud, so to type. It's been a while since I last thought hard about the consequences of changes to the LLVM IR. Back In the 2.x series, LLVM had an OpaqueType that could take the place of any type. It was something that might be resolved as part of linking, and this made module linking pretty complicated as opaques got resolved (not to mention the rest of LLVM had to deal with opaques though really except it didn't really inside function bodies). OpaqueType was restricted to StructType by 2.9 in preparation for the 3.0 change. I want to make sure that having a replacement for OpaqueType that's restricted to pointers doesn't reintroduce most of the same problems. After all, pointers aren't the only type that have elements, why not array types? Array types can have struct elements and struct elements can have array types, so we'll still need to do a recursive check that a type is acyclic when constructed. That doesn't sound too bad, though I think it will have to be O(n^2) unless you can get it in the right data representation to use Tarjan's algorithm which will probably be tricky. It seems that the big difference here (vs. LLVM 2.9) is that we can have opaque pointers propagated through the whole IR including all the instructions that operate on pointers. Then when linking we match up types by structure and we never have to do any type refinement. The remaining challenge here is forward declared structs, we want those to match up by name during module linking, but is there any reason that can't be handled the same as current LLVM does it? Same name in two modules, if both have bodies one gets renamed, otherwise they're the same type. The name can then live on the module and not the context. StructType::setBody can still be used to take a struct from body-less to one with a body, though it still has to check for non-pointer recursive types on construction. Ah, but you never need to because the only way to get a legal cycle is through a pointer anyhow! So you still need empty-body structs for the forward declaration case (as in, the original C code used a forward-declared struct -- note that struct Foo; struct Foo f(); returning a non-pointer forward declared struct is valid in C) to handle module linking, but that's the only case, in all other cases you can pass in all fields at construction time. So you don't really need setBody at all, the module linker just has to change the types from the opaque one to the one with a body when moving the values.

Ok, I like this plan. Best of luck!

Thanks for thinking it through! I also appreciate hearing about the the pre-3.0 days; I wasn't aware of that history (and how we're revisiting similar solutions).

Note that if you want more discussion of the opaque pointers, David gave an LLVM talk a while ago (https://www.youtube.com/watch?v=OWgWDx_gB1I). He left a few exercises for the viewer/listener which I think are slowly being worked through (I've been following it mostly from a distance, but it appears to be getting close).

[dblaikie]

Thanks for thinking it through! I also appreciate hearing about the the pre-3.0 days; I wasn't aware of that history (and how we're revisiting similar solutions).

Yeah, appreciate the thoughts/context. (I came in /just/ after the 3.0 days - some of my first patches were cleaning up/removing "const" on "const Type" because Type was now immutable)

Note that if you want more discussion of the opaque pointers, David gave an LLVM talk a while ago (https://www.youtube.com/watch?v=OWgWDx_gB1I). He left a few exercises for the viewer/listener which I think are slowly being worked through (I've been following it mostly from a distance, but it appears to be getting close).

Yep, that's about the size of it. Few folks have chipped in here and there - glad to help/might be able to pick up some of it myself here and there.

llvm/include/llvm-c/Core.h

 
 /**
  * Check for the different types of attributes.
  */
 LLVMBool LLVMIsEnumAttribute(LLVMAttributeRef A);
 LLVMBool LLVMIsStringAttribute(LLVMAttributeRef A);
 
 /**
+ * Obtain a Type from a context by its registered name.
+ */
+LLVMTypeRef LLVMGetTypeByName2(LLVMContextRef C, const char *Name);
+
+/**
  * @}
  */
 
 /**
  * @defgroup LLVMCCoreModule Modules
  *
  * Modules represent the top-level structure in an LLVM program. An LLVM
  * module is effectively a translation unit or a collection of

 
 /**
  * Obtain the context to which this module is associated.
  *
  * @see Module::getContext()
  */
 LLVMContextRef LLVMGetModuleContext(LLVMModuleRef M);
 
-/**
- * Obtain a Type from a module by its registered name.
- */
+/** Deprecated: Use LLVMGetTypeByName2 instead. */
 LLVMTypeRef LLVMGetTypeByName(LLVMModuleRef M, const char *Name);
 
 /**
  * Obtain an iterator to the first NamedMDNode in a Module.
  *
  * @see llvm::Module::named_metadata_begin()
  */
 LLVMNamedMDNodeRef LLVMGetFirstNamedMetadata(LLVMModuleRef M);

llvm/include/llvm/IR/DerivedTypes.h

public:
   static std::enable_if_t<are_base_of<Type, Tys...>::value, StructType *>
   get(Type *elt1, Tys *... elts) {
     assert(elt1 && "Cannot create a struct type with no elements with this");
     LLVMContext &Ctx = elt1->getContext();
     SmallVector<llvm::Type *, 8> StructFields({elt1, elts...});
     return llvm::StructType::get(Ctx, StructFields);
   }
 
+  /// Return the type with the specified name, or null if there is none by that
+  /// name.
+  static StructType *getTypeByName(LLVMContext &C, StringRef Name);
+
   bool isPacked() const { return (getSubclassData() & SCDB_Packed) != 0; }
 
   /// Return true if this type is uniqued by structural equivalence, false if it
   /// is a struct definition.
   bool isLiteral() const { return (getSubclassData() & SCDB_IsLiteral) != 0; }
 
   /// Return true if this is a type with an identity that has no body specified
   /// yet. These prints as 'opaque' in .ll files.

llvm/lib/Frontend/OpenMP/OMPConstants.cpp

 #define OMP_TYPE(VarName, InitValue) VarName = InitValue;
 #define OMP_ARRAY_TYPE(VarName, ElemTy, ArraySize)                             \
   VarName##Ty = ArrayType::get(ElemTy, ArraySize);                             \
   VarName##PtrTy = PointerType::getUnqual(VarName##Ty);
 #define OMP_FUNCTION_TYPE(VarName, IsVarArg, ReturnType, ...)                  \
   VarName = FunctionType::get(ReturnType, {__VA_ARGS__}, IsVarArg);            \
   VarName##Ptr = PointerType::getUnqual(VarName);
 #define OMP_STRUCT_TYPE(VarName, StructName, ...)                              \
-  T = M.getTypeByName(StructName);                                             \
+  T = StructType::getTypeByName(Ctx, StructName);                              \
   if (!T)                                                                      \
     T = StructType::create(Ctx, {__VA_ARGS__}, StructName);                    \
   VarName = T;                                                                 \
   VarName##Ptr = PointerType::getUnqual(T);
 #include "llvm/Frontend/OpenMP/OMPKinds.def"
 }
 
 void llvm::omp::types::uninitializeTypes() {

llvm/lib/IR/Core.cpp

LLVMBool LLVMIsOpaqueStruct(LLVMTypeRef StructTy) {
   return unwrap<StructType>(StructTy)->isOpaque();
 }
 
 LLVMBool LLVMIsLiteralStruct(LLVMTypeRef StructTy) {
   return unwrap<StructType>(StructTy)->isLiteral();
 }
 
 LLVMTypeRef LLVMGetTypeByName(LLVMModuleRef M, const char *Name) {
-  return wrap(unwrap(M)->getTypeByName(Name));
+  return wrap(StructType::getTypeByName(unwrap(M)->getContext(), Name));
+}
+
+LLVMTypeRef LLVMGetTypeByName2(LLVMContextRef C, const char *Name) {
+  return wrap(StructType::getTypeByName(*unwrap(C), Name));
 }
 
 /*--.. Operations on array, pointer, and vector types (sequence types) .....--*/
 
 void LLVMGetSubtypes(LLVMTypeRef Tp, LLVMTypeRef *Arr) {
     int i = 0;
     for (auto *T : unwrap(Tp)->subtypes()) {
         Arr[i] = wrap(T);

llvm/lib/IR/Type.cpp

bool StructType::isLayoutIdentical(StructType *Other) const {
   if (this == Other) return true;
 
   if (isPacked() != Other->isPacked())
     return false;
 
   return elements() == Other->elements();
 }
 
-StructType *Module::getTypeByName(StringRef Name) const {
-  return getContext().pImpl->NamedStructTypes.lookup(Name);
-}
-
 Type *StructType::getTypeAtIndex(const Value *V) const {
   unsigned Idx = (unsigned)cast<Constant>(V)->getUniqueInteger().getZExtValue();
   assert(indexValid(Idx) && "Invalid structure index!");
   return getElementType(Idx);
 }
 
 bool StructType::indexValid(const Value *V) const {
   // Structure indexes require (vectors of) 32-bit integer constants.  In the
   // vector case all of the indices must be equal.
   if (!V->getType()->isIntOrIntVectorTy(32))
     return false;
   const Constant *C = dyn_cast<Constant>(V);
   if (C && V->getType()->isVectorTy())
     C = C->getSplatValue();
   const ConstantInt *CU = dyn_cast_or_null<ConstantInt>(C);
   return CU && CU->getZExtValue() < getNumElements();
 }
 
+StructType *StructType::getTypeByName(LLVMContext &C, StringRef Name) {
+  return C.pImpl->NamedStructTypes.lookup(Name);
+}
+
 //===----------------------------------------------------------------------===//
 //                           ArrayType Implementation
 //===----------------------------------------------------------------------===//
 
 ArrayType::ArrayType(Type *ElType, uint64_t NumEl)
     : Type(ElType->getContext(), ArrayTyID), ContainedType(ElType),
       NumElements(NumEl) {
   ContainedTys = &ContainedType;

llvm/lib/Linker/IRMover.cpp

if (TypeMap.DstStructTypesSet.hasType(ST)) {
       // This is actually a type from the destination module.
       // getIdentifiedStructTypes() can have found it by walking debug info
       // metadata nodes, some of which get linked by name when ODR Type Uniquing
       // is enabled on the Context, from the source to the destination module.
       continue;
     }
 
     auto STTypePrefix = getTypeNamePrefix(ST->getName());
-    if (STTypePrefix.size()== ST->getName().size())
+    if (STTypePrefix.size() == ST->getName().size())
       continue;
 
     // Check to see if the destination module has a struct with the prefix name.
-    StructType *DST = DstM.getTypeByName(STTypePrefix);
+    StructType *DST = StructType::getTypeByName(ST->getContext(), STTypePrefix);
     if (!DST)
       continue;
 
     // Don't use it if this actually came from the source module. They're in
     // the same LLVMContext after all. Also don't use it unless the type is
     // actually used in the destination module. This can happen in situations
     // like this:
     //

llvm/tools/llvm-c-test/echo.cpp

switch (Kind) {
         if (ParamCount > 0)
           free(Params);
         return FunTy;
       }
       case LLVMStructTypeKind: {
         LLVMTypeRef S = nullptr;
         const char *Name = LLVMGetStructName(Src);
         if (Name) {
-          S = LLVMGetTypeByName(M, Name);
+          S = LLVMGetTypeByName2(Ctx, Name);
           if (S)
             return S;
           S = LLVMStructCreateNamed(Ctx, Name);
           if (LLVMIsOpaqueStruct(Src))
             return S;
         }
 
         unsigned EltCount = LLVMCountStructElementTypes(Src);

llvm/unittests/Analysis/TargetLibraryInfoTest.cpp

 };
 
 } // end anonymous namespace
 
 // Check that we don't accept egregiously incorrect prototypes.
 TEST_F(TargetLibraryInfoTest, InvalidProto) {
   parseAssembly("%foo = type { %foo }\n");
 
-  auto *StructTy = M->getTypeByName("foo");
+  auto *StructTy = StructType::getTypeByName(Context, "foo");
   auto *InvalidFTy = FunctionType::get(StructTy, /*isVarArg=*/false);
 
   for (unsigned FI = 0; FI != LibFunc::NumLibFuncs; ++FI) {
     LibFunc LF = (LibFunc)FI;
     auto *F = cast<Function>(
         M->getOrInsertFunction(TLI.getName(LF), InvalidFTy).getCallee());
     EXPECT_FALSE(isLibFunc(F, LF));
   }

polly/lib/CodeGen/LoopGeneratorsKMP.cpp

 using namespace polly;
 
 void ParallelLoopGeneratorKMP::createCallSpawnThreads(Value *SubFn,
                                                       Value *SubFnParam,
                                                       Value *LB, Value *UB,
                                                       Value *Stride) {
   const std::string Name = "__kmpc_fork_call";
   Function *F = M->getFunction(Name);
-  Type *KMPCMicroTy = M->getTypeByName("kmpc_micro");
+  Type *KMPCMicroTy = StructType::getTypeByName(M->getContext(), "kmpc_micro");
 
   if (!KMPCMicroTy) {
     // void (*kmpc_micro)(kmp_int32 *global_tid, kmp_int32 *bound_tid, ...)
     Type *MicroParams[] = {Builder.getInt32Ty()->getPointerTo(),
                            Builder.getInt32Ty()->getPointerTo()};
 
     KMPCMicroTy = FunctionType::get(Builder.getVoidTy(), MicroParams, true);
   }
 
   // If F is not available, declare it.
   if (!F) {
-    StructType *IdentTy = M->getTypeByName("struct.ident_t");
+    StructType *IdentTy =
+        StructType::getTypeByName(M->getContext(), "struct.ident_t");
 
     GlobalValue::LinkageTypes Linkage = Function::ExternalLinkage;
     Type *Params[] = {IdentTy->getPointerTo(), Builder.getInt32Ty(),
                       KMPCMicroTy->getPointerTo()};
 
     FunctionType *Ty = FunctionType::get(Builder.getVoidTy(), Params, true);
     F = Function::Create(Ty, Linkage, Name, M);
   }

 }
 
 Value *ParallelLoopGeneratorKMP::createCallGlobalThreadNum() {
   const std::string Name = "__kmpc_global_thread_num";
   Function *F = M->getFunction(Name);
 
   // If F is not available, declare it.
   if (!F) {
-    StructType *IdentTy = M->getTypeByName("struct.ident_t");
+    StructType *IdentTy =
+        StructType::getTypeByName(M->getContext(), "struct.ident_t");
 
     GlobalValue::LinkageTypes Linkage = Function::ExternalLinkage;
     Type *Params[] = {IdentTy->getPointerTo()};
 
     FunctionType *Ty = FunctionType::get(Builder.getInt32Ty(), Params, false);
     F = Function::Create(Ty, Linkage, Name, M);
   }
 
   return Builder.CreateCall(F, {SourceLocationInfo});
 }
 
 void ParallelLoopGeneratorKMP::createCallPushNumThreads(Value *GlobalThreadID,
                                                         Value *NumThreads) {
   const std::string Name = "__kmpc_push_num_threads";
   Function *F = M->getFunction(Name);
 
   // If F is not available, declare it.
   if (!F) {
-    StructType *IdentTy = M->getTypeByName("struct.ident_t");
+    StructType *IdentTy =
+        StructType::getTypeByName(M->getContext(), "struct.ident_t");
 
     GlobalValue::LinkageTypes Linkage = Function::ExternalLinkage;
     Type *Params[] = {IdentTy->getPointerTo(), Builder.getInt32Ty(),
                       Builder.getInt32Ty()};
 
     FunctionType *Ty = FunctionType::get(Builder.getVoidTy(), Params, false);
     F = Function::Create(Ty, Linkage, Name, M);
   }
 
   Value *Args[] = {SourceLocationInfo, GlobalThreadID, NumThreads};
 
   Builder.CreateCall(F, Args);
 }
 
 void ParallelLoopGeneratorKMP::createCallStaticInit(Value *GlobalThreadID,
                                                     Value *IsLastPtr,
                                                     Value *LBPtr, Value *UBPtr,
                                                     Value *StridePtr,
                                                     Value *ChunkSize) {
   const std::string Name =
       is64BitArch() ? "__kmpc_for_static_init_8" : "__kmpc_for_static_init_4";
   Function *F = M->getFunction(Name);
-  StructType *IdentTy = M->getTypeByName("struct.ident_t");
+  StructType *IdentTy =
+      StructType::getTypeByName(M->getContext(), "struct.ident_t");
 
   // If F is not available, declare it.
   if (!F) {
     GlobalValue::LinkageTypes Linkage = Function::ExternalLinkage;
 
     Type *Params[] = {IdentTy->getPointerTo(),
                       Builder.getInt32Ty(),
                       Builder.getInt32Ty(),
Value *Args[] = {
       ChunkSize};
 
   Builder.CreateCall(F, Args);
 }
 
 void ParallelLoopGeneratorKMP::createCallStaticFini(Value *GlobalThreadID) {
   const std::string Name = "__kmpc_for_static_fini";
   Function *F = M->getFunction(Name);
-  StructType *IdentTy = M->getTypeByName("struct.ident_t");
+  StructType *IdentTy =
+      StructType::getTypeByName(M->getContext(), "struct.ident_t");
 
   // If F is not available, declare it.
   if (!F) {
     GlobalValue::LinkageTypes Linkage = Function::ExternalLinkage;
     Type *Params[] = {IdentTy->getPointerTo(), Builder.getInt32Ty()};
     FunctionType *Ty = FunctionType::get(Builder.getVoidTy(), Params, false);
     F = Function::Create(Ty, Linkage, Name, M);
   }
 
   Value *Args[] = {SourceLocationInfo, GlobalThreadID};
 
   Builder.CreateCall(F, Args);
 }
 
 void ParallelLoopGeneratorKMP::createCallDispatchInit(Value *GlobalThreadID,
                                                       Value *LB, Value *UB,
                                                       Value *Inc,
                                                       Value *ChunkSize) {
   const std::string Name =
       is64BitArch() ? "__kmpc_dispatch_init_8" : "__kmpc_dispatch_init_4";
   Function *F = M->getFunction(Name);
-  StructType *IdentTy = M->getTypeByName("struct.ident_t");
+  StructType *IdentTy =
+      StructType::getTypeByName(M->getContext(), "struct.ident_t");
 
   // If F is not available, declare it.
   if (!F) {
     GlobalValue::LinkageTypes Linkage = Function::ExternalLinkage;
 
     Type *Params[] = {IdentTy->getPointerTo(),
                       Builder.getInt32Ty(),
                       Builder.getInt32Ty(),

 Value *ParallelLoopGeneratorKMP::createCallDispatchNext(Value *GlobalThreadID,
                                                         Value *IsLastPtr,
                                                         Value *LBPtr,
                                                         Value *UBPtr,
                                                         Value *StridePtr) {
   const std::string Name =
       is64BitArch() ? "__kmpc_dispatch_next_8" : "__kmpc_dispatch_next_4";
   Function *F = M->getFunction(Name);
-  StructType *IdentTy = M->getTypeByName("struct.ident_t");
+  StructType *IdentTy =
+      StructType::getTypeByName(M->getContext(), "struct.ident_t");
 
   // If F is not available, declare it.
   if (!F) {
     GlobalValue::LinkageTypes Linkage = Function::ExternalLinkage;
 
     Type *Params[] = {IdentTy->getPointerTo(),
                       Builder.getInt32Ty(),
                       Builder.getInt32Ty()->getPointerTo(),

 // TODO: This function currently creates a source location dummy. It might be
 // necessary to (actually) provide information, in the future.
 GlobalVariable *ParallelLoopGeneratorKMP::createSourceLocation() {
   const std::string LocName = ".loc.dummy";
   GlobalVariable *SourceLocDummy = M->getGlobalVariable(LocName);
 
   if (SourceLocDummy == nullptr) {
     const std::string StructName = "struct.ident_t";
-    StructType *IdentTy = M->getTypeByName(StructName);
+    StructType *IdentTy =
+        StructType::getTypeByName(M->getContext(), StructName);
 
     // If the ident_t StructType is not available, declare it.
     // in LLVM-IR: ident_t = type { i32, i32, i32, i32, i8* }
     if (!IdentTy) {
       Type *LocMembers[] = {Builder.getInt32Ty(), Builder.getInt32Ty(),
                             Builder.getInt32Ty(), Builder.getInt32Ty(),
                             Builder.getInt8PtrTy()};