llvm-link: Add module flag behavior MergeTargetID

[yaxunl]

Summary

Target ID is a module flag metadata needed by HIP language. Its key is 'target-id'

Its format is a list of strings delimited by ':', e.g. amdgcn-amd-amdhsa--gfx908:xnack+:sramecc-. The first string is
triple-cpu. The other strings are called feature string which may or may not be target features.
Except for the id string, all feature strings end with '+' or '-'.

A new module flag behavior is needed for merging module flags in this format.

The rule is:

1. module with target-id module flag can only link with module with target-id module flag

2. empty target ID can merge with any target ID

3. If neither target ID is empty, the triple-cpu must match

4. the triple-cpu string and existing features of the destination target ID are kept

5. If a feature is in both source and destination target ID, they must have the same sign, otherwise it results in a conflict module flag error.

6. If a feature is in source target ID but not in destination target ID, it is added to destination target ID

[yaxunl]

do not allow a module having target id to link with a module not having target id

[scott.linder]

llvm/docs/LangRef.rst

6488

Do we have a canonical definition of "TargetID" somewhere? I know it isn't updated yet, but would https://llvm.org/docs/AMDGPUUsage.html#code-object-target-identification be a reasonable place?

The format is general enough for any target to use, so maybe it should be described somewhere else and linked to from AMDGPUUsage?

6492

Can this explicitly mention that mismatched triple-cpu causes an error?

llvm/lib/Linker/IRMover.cpp

1207

Shouldn't the second operand, the "unique ID" of the metadata, be considered too? There could be many unrelated metadata flags which all use the MergeTargetID behavior, and this seems like it will conflate them. Could you add a test for this case too?

1409

Can these be explicitly typed as StringRef? It wasn't clear to me reading it the first time, especially seeing the cast first.

1413

Can this mention that the first ':' delimits the "<triple>-<cpu>" portion from the features, which are then also delimited by ':'?

1454

Could you use either id or ID everywhere consistently, including comments? I would prefer ID

1468

Why is this done nested within the merging of features; can this instead be done once, early on?

[yaxunl]

fix typo in tests

[yaxunl]

revised by Scott's comments.

[yaxunl]

llvm/docs/LangRef.rst

6488

I will update AMDGPUUsage to include definition of target ID and add a link to that.

I am not sure if there is a better place for target ID definition. It is a concept that are used in AMDGPU code object bundle, LLVM IR module flag, and clang option. Consider these three places, it seems AMDGPUusage is best since it is the place where the concept is originated.

6492

done

llvm/lib/Linker/IRMover.cpp

1207

since this module flag behavior is only used for target ID, I specified in the documentation that the key must be target-id if the module flag behavior is MergeTargetID, and added check to verifier to make sure the key is target-id when module flag behavior is MergeTargetID. Also added lit test.

1409

done

1413

done

1454

done

[jdoerfert]

Except for the id string, all feature strings end with '+' or '-'.

Except for the triple string you mean?

What is the difference to the "target-features" attribute we have? Shouldn't we use the same encoding instead of inventing yet another one?

llvm/docs/LangRef.rst

6493

This sounds an awful lot like mismatches in regular target triples. Do we really need a new mechanism and wording here, and if so, couldn't we restrict it to the features? I mean, there is a target triple already in the module, right?

[yaxunl]

In D80750#2160567, @jdoerfert wrote:

Except for the id string, all feature strings end with '+' or '-'.

Except for the triple string you mean?

should be triple-cpu string.

What is the difference to the "target-features" attribute we have? Shouldn't we use the same encoding instead of inventing yet another one?

In the future, target ID may introduce key=value entries. Let the key before value will make it consistent.

[yaxunl]

llvm/docs/LangRef.rst

6493

Yes. It is a design decision made by AMD after thorough internal discussions.

We need to have an efficient way to identify device binaries embedded in a host executable for single source languages e.g. HIP. There are multiple device binaries embedded. The device binaries are not just per processor, they are per processor/feature combination. We do not want to encode features in GPU names since it incurs combination explosion. In stead, we need to use processor:feature1+:feature2+ (so called target ID) to identify a device binary.

The target ID is a real ID to identify a device binary. It is specified by user to clang and will be passed to backend to embed in device binary to be used by runtime. Since it is per module, it needs to be represented as a module flag. And since modules with different target ID may be linked together, they need to be checked to ensure compatibility and merged if necessary.

Checking target feature directly is not suitable here since target feature is per function. Also not all target features are part of target ID.

Currently target ID is only supported by AMDGPU target. It is NFC for other targets. However it can be adopted by other targets easily.

[jdoerfert]

llvm/docs/LangRef.rst

6493

Yes. It is a design decision made by AMD after thorough internal discussions.

Given that this is a problem for various people and languages, maybe such a discussion should happen in the open such that we implement a solution which can be used by HIP, OPENMP, CUDA, SYCL, ...

As an alternative design, I have (for a while now) a prototype to allow multi-target LLVM-IR modules. It seems that would solve your problem as well but (IMHO) closer aligned to what we use "usually" to define the target (namely the target string in the module).

I'll share my prototype this week and start a discussion. Feel free to let me know beforehand what you think.

[yaxunl]

llvm/docs/LangRef.rst

6493

Have you shared your prototype? We would like to evaluate using it in place of the module flag. Thanks.

[jdoerfert]

llvm/docs/LangRef.rst

6493

Sorry for the wait, this was not good of me.

I wrote the email I was postponing for months: http://lists.llvm.org/pipermail/llvm-dev/2020-July/143808.html
And you can see one way of having different targets in one module prototyped in D84728.

Please let me know what you think.

[yaxunl]

llvm/docs/LangRef.rst

6493

Thanks for sharing the info.

Overall I support the idea of heterogeneous LLVM IR and I think this is the right direction. I would like to suggest to make global values not per triple but per triple-processor, since the IR of a function depends on processor in general. Another issue is that the name of global value may be different for different triple, e.g. when compiling on Windows with MSVC, the host IR and device IR may use different name mangling scheme.

I can see it will take considerable efforts and time to adopt the heterogeneous IR in the compiler pipe line. I don't think it is feasible to defer all the current feature development which are potentially rely on heterogeneous IR. A feasible approach is that how to transit this feature to heterogeneous IR when time comes.

My patch introduced a target-id module flag, which is actually a generalization of triple-processor module flag. We need this since we need it in llvm codegen and also we want to check compatibility of modules when linking.

The current implementation does not consider heterogeneous IR. From what I see, we still need a module flag to convey the information about what triple-processors this heterogeneous IR is compiled for. The difference is that now it becomes a list of triple-processors instead of just one triple-processor. At least this will be true for amdgpu target. Since this module flag is optional, a target can choose to use it or not, so it will have no impact on other targets.

So what I need to do is to make it future proof. Basically instead of assuming each module has one target ID, assuming each module can have a list of target ID's.

[jdoerfert]

I believe there are three things in this patch, but feel free to correct me:

1. A way to specify a target triple + cpu. Basically like target triple = ... but in the module metadata plus some additional target cpu suffix, which is so far in the target-cpu function attribute list.
2. A way to specify global target features, which are so far in the target-features function attribute list.
3. Making llvm-link aware of 1) and 2) and verifying they match (under some rules).

If this is the case, what is the benefit over a toplevel module entry that allows you to specify target-cpu and target-feature for the entire module? I mean, they seem to be very much the same thing as target triple, yet we go a totally different route to add them and verify the match during linking. I believe other people might benefit from this, e.g., to get rid of function-level attributes, so we should shoot for a generic solution.

llvm/docs/LangRef.rst

6493

Could you also respond on the list. The feedback is very valuable and has more reach there :)

I am not (trying to) blocking this patch but I still doubt it is the right direction. We have too many levels of triple and features and this is yet another one which will only solve a particular problem you are having right now (as far as I can tell).

[yaxunl]

In D80750#2180284, @jdoerfert wrote:

I believe there are three things in this patch, but feel free to correct me:

1. A way to specify a target triple + cpu. Basically like target triple = ... but in the module metadata plus some additional target cpu suffix, which is so far in the target-cpu function attribute list.
2. A way to specify global target features, which are so far in the target-features function attribute list.
3. Making llvm-link aware of 1) and 2) and verifying they match (under some rules).

If this is the case, what is the benefit over a toplevel module entry that allows you to specify target-cpu and target-feature for the entire module? I mean, they seem to be very much the same thing as target triple, yet we go a totally different route to add them and verify the match during linking. I believe other people might benefit from this, e.g., to get rid of function-level attributes, so we should shoot for a generic solution.

The matching and merging rule we want to apply to the target features in target ID is not generic for arbitrary target features. We can apply these rules to target features only if they appear in a target ID.

Also we do not see strong motivation to enforce matching of target-cpu in general, otherwise such a rule should have been added to the linker. However, for target ID we have reasons to enforce such checking.

target ID is documented in https://reviews.llvm.org/D84822 It is general enough to be adopted by any targets if it is needed. In the degenerated case it can be simply the processor, in more general case it can includes target features that need to be consistent across modules. The usage of target-id module flag is like a contract saying that what needs to be matched, whereas in general such matching is not required.

[jdoerfert]

In D80750#2181709, @yaxunl wrote:

In D80750#2180284, @jdoerfert wrote:

I believe there are three things in this patch, but feel free to correct me:

1. A way to specify a target triple + cpu. Basically like target triple = ... but in the module metadata plus some additional target cpu suffix, which is so far in the target-cpu function attribute list.
2. A way to specify global target features, which are so far in the target-features function attribute list.
3. Making llvm-link aware of 1) and 2) and verifying they match (under some rules).

If this is the case, what is the benefit over a toplevel module entry that allows you to specify target-cpu and target-feature for the entire module? I mean, they seem to be very much the same thing as target triple, yet we go a totally different route to add them and verify the match during linking. I believe other people might benefit from this, e.g., to get rid of function-level attributes, so we should shoot for a generic solution.

The matching and merging rule we want to apply to the target features in target ID is not generic for arbitrary target features. We can apply these rules to target features only if they appear in a target ID.

Could you elaborate why this doesn't apply to arbitrary target features? Where and how is decided what is an OK feature and how they are merged? When I look at the merging procedure in the llvm/lib/Linker/IRMover.cpp I don't see any code that is not generic and applies to arbitrary target feature. It looks like you say a feature present in both needs to have the same sign and the union of features is used for the resulting module, correct? I would assume I can write +foobar in one or two module "target-id" metadata and they will be merged just fine with this patch, is this wrong?

Also we do not see strong motivation to enforce matching of target-cpu in general, otherwise such a rule should have been added to the linker. However, for target ID we have reasons to enforce such checking.

If you have them named in global scope and allow each global symbol to reference one, you don't have to enforce matching in general or at all. But you can choose to require at most one (or compatible ones) for the AMDGPU backend. This patch has a single rule that suits your needs now, target-cpu is module wide and has to match, which is way less flexible.

target ID is documented in https://reviews.llvm.org/D84822 It is general enough to be adopted by any targets if it is needed. In the degenerated case it can be simply the processor, in more general case it can includes target features that need to be consistent across modules. The usage of target-id module flag is like a contract saying that what needs to be matched, whereas in general such matching is not required.

All of this would be true for (named) global target id/features on module level as well, wouldn't it? What makes this a module flag thing as opposed to be at the same level with target triple? Especially if we have other reasons to have multiple target triples anyway. This is adding a completely new scheme with hardcoded rules in a completely different way than the existing scheme works.

[yaxunl]

In D80750#2183604, @jdoerfert wrote:

In D80750#2181709, @yaxunl wrote:

In D80750#2180284, @jdoerfert wrote:

I believe there are three things in this patch, but feel free to correct me:

1. A way to specify a target triple + cpu. Basically like target triple = ... but in the module metadata plus some additional target cpu suffix, which is so far in the target-cpu function attribute list.
2. A way to specify global target features, which are so far in the target-features function attribute list.
3. Making llvm-link aware of 1) and 2) and verifying they match (under some rules).

If this is the case, what is the benefit over a toplevel module entry that allows you to specify target-cpu and target-feature for the entire module? I mean, they seem to be very much the same thing as target triple, yet we go a totally different route to add them and verify the match during linking. I believe other people might benefit from this, e.g., to get rid of function-level attributes, so we should shoot for a generic solution.

The matching and merging rule we want to apply to the target features in target ID is not generic for arbitrary target features. We can apply these rules to target features only if they appear in a target ID.

Could you elaborate why this doesn't apply to arbitrary target features? Where and how is decided what is an OK feature and how they are merged? When I look at the merging procedure in the llvm/lib/Linker/IRMover.cpp I don't see any code that is not generic and applies to arbitrary target feature. It looks like you say a feature present in both needs to have the same sign and the union of features is used for the resulting module, correct? I would assume I can write +foobar in one or two module "target-id" metadata and they will be merged just fine with this patch, is this wrong?

There are different kinds of target features. Some features are for optimization purpose, therefore a module compiled with such a feature on can be linked with a module with such feature off without problem. For such features, our target ID rule for feature matching does not apply, since we do not allow a module with a feature on to be linked with the same feature off.

Not all features are allowed in target ID. The features allowed in target ID have special traits and requirements:

1. They correspond to a processor configuration which cannot be changed dynamically
2. The ISA generated with such feature on can only be loaded on a processor with such feature on. The ISA generated with such feature off can only be loaded on a processor with such a feature off. That's why there is a rule that a module with such a feature on can not be linked with a module with the same feature off.
3. It is required such features have a default value which works with the processor configured in either way. If the feature is not specified in target ID, it takes the default value. Therefore a LLVM module compiled without such explicit feature can be linked with a LLVM module compiled with this feature explicitly on/off. This is not generally true for arbitrary features.

In a summary, when a feature shows up in target ID, there is guarantee that they satisfy these traits and requirements, therefore they need the matching/merging rule that is defined for target ID. Whereas an arbitrary feature does not satisfy these traits and requirements.

Basically the features in target ID together with processor are used to identify the processor and its configuration for what an LLVM module is compiled for. As such, it is better to be as one entity, instead of split up as processor and features.

Also we do not see strong motivation to enforce matching of target-cpu in general, otherwise such a rule should have been added to the linker. However, for target ID we have reasons to enforce such checking.

If you have them named in global scope and allow each global symbol to reference one, you don't have to enforce matching in general or at all. But you can choose to require at most one (or compatible ones) for the AMDGPU backend. This patch has a single rule that suits your needs now, target-cpu is module wide and has to match, which is way less flexible.

target ID is documented in https://reviews.llvm.org/D84822 It is general enough to be adopted by any targets if it is needed. In the degenerated case it can be simply the processor, in more general case it can includes target features that need to be consistent across modules. The usage of target-id module flag is like a contract saying that what needs to be matched, whereas in general such matching is not required.

All of this would be true for (named) global target id/features on module level as well, wouldn't it? What makes this a module flag thing as opposed to be at the same level with target triple? Especially if we have other reasons to have multiple target triples anyway. This is adding a completely new scheme with hardcoded rules in a completely different way than the existing scheme works.

I think representing target ID at module level in a similar way like triple is a good idea, since this will make it compatible with heterogeneous IR.

llvm/docs/LangRef.rst

- **AppendUnique**
            Appends the two values, which are required to be metadata
            nodes. However, duplicate entries in the second list are dropped
            during the append operation.
 
    * - 7
      - **Max**
            Takes the max of the two values, which are required to be integers.
 
+   * - 8
+     - **MergeTargetID**
+           Merge two string values in the format of triple-`target-ID
+           <https://llvm.org/docs/AMDGPUUsage.html#target-ids>`.
+           The key must be `target-id`. If there is a mismatch in triple or
+           processor of the source and destination target ID's, or if a feature
+           is in both source and destination target ID's but with different
+           signs, an error of conflict module flags will be emitted.
+
 It is an error for a particular unique flag ID to have multiple behaviors,
 except in the case of **Require** (which adds restrictions on another metadata
 value) or **Override**.
 
 An example of module flags:
 
 .. code-block:: llvm
 

llvm/include/llvm/IR/Module.h

enum ModFlagBehavior {
     /// Appends the two values, which are required to be metadata
     /// nodes. However, duplicate entries in the second list are dropped
     /// during the append operation.
     AppendUnique = 6,
 
     /// Takes the max of the two values, which are required to be integers.
     Max = 7,
 
+    /// Merge target ids.
+    MergeTargetID = 8,
+
     // Markers:
     ModFlagBehaviorFirstVal = Error,
-    ModFlagBehaviorLastVal = Max
+    ModFlagBehaviorLastVal = MergeTargetID
   };
 
   /// Checks if Metadata represents a valid ModFlagBehavior, and stores the
   /// converted result in MFB.
   static bool isValidModFlagBehavior(Metadata *MD, ModFlagBehavior &MFB);
 
   /// Check if the given module flag metadata represents a valid module flag,
   /// and store the flag behavior, the key string and the value metadata.

llvm/lib/IR/Verifier.cpp

Verifier::visitModuleFlag(const MDNode *Op,
 
   case Module::Max: {
     Assert(mdconst::dyn_extract_or_null<ConstantInt>(Op->getOperand(2)),
            "invalid value for 'max' module flag (expected constant integer)",
            Op->getOperand(2));
     break;
   }
 
+  case Module::MergeTargetID: {
+    Assert(ID->getString() == "target-id",
+           "Invalid key for 'MergeTargetID' module flag (expected 'target-id')",
+           Op->getOperand(1));
+    Assert(dyn_cast_or_null<MDString>(Op->getOperand(2)),
+           "invalid value for 'MergeTargetID' module flag (expected string)",
+           Op->getOperand(2));
+    break;
+  }
+
   case Module::Require: {
     // The value should itself be an MDNode with two operands, a flag ID (an
     // MDString), and a value.
     MDNode *Value = dyn_cast<MDNode>(Op->getOperand(2));
     Assert(Value && Value->getNumOperands() == 2,
            "invalid value for 'require' module flag (expected metadata pair)",
            Op->getOperand(2));
     Assert(isa<MDString>(Value->getOperand(0)),

llvm/lib/Linker/IRMover.cpp

for (const NamedMDNode &NMD : SrcM->named_metadata()) {
     // Add Src elements into Dest node.
     for (const MDNode *Op : NMD.operands())
       DestNMD->addOperand(Mapper.mapMDNode(*Op));
   }
 }
 
 /// Merge the linker flags in Src into the Dest module.
 Error IRLinker::linkModuleFlagsMetadata() {
+  // A module with MergeTargetID is not allowed to link with a module
+  // without MergeTargetID.
+  auto HasMergeTargetIDBehavior = [](Module &M) {
+    auto *ModFlags = M.getModuleFlagsMetadata();
+    if (!ModFlags)
+      return false;
+    for (unsigned I = 0, E = ModFlags->getNumOperands(); I != E; ++I) {
+      MDNode *Op = ModFlags->getOperand(I);
+      ConstantInt *Behavior = mdconst::extract<ConstantInt>(Op->getOperand(0));
+      if (Behavior->getZExtValue() == Module::MergeTargetID)
+        return true;
+    }
+    return false;
+  };
+  // llvm-link starts with an empty module and adds modules one by one. We
+  // have to allow the empty module to link with any other module.
+  if (DstM.getModuleFlagsMetadata()) {
+    bool SrcHasTargetID = HasMergeTargetIDBehavior(*SrcM);
+    bool DstHasTargetID = HasMergeTargetIDBehavior(DstM);
+    if (SrcHasTargetID != DstHasTargetID) {
+      auto *HasM = SrcHasTargetID ? &*SrcM : &DstM;
+      auto *NoM = SrcHasTargetID ? &DstM : &*SrcM;
+      return stringErr("cannot link '" + HasM->getModuleIdentifier() +
+                       "' which has target-id with '" +
+                       NoM->getModuleIdentifier() +
+                       "' which does not have target-id.");
+    }
+  }
+
   // If the source module has no module flags, we are done.
   const NamedMDNode *SrcModFlags = SrcM->getModuleFlagsMetadata();
   if (!SrcModFlags)
     return Error::success();
 
   // If the destination module doesn't have module flags yet, then just copy
   // over the source module's flags.
   NamedMDNode *DstModFlags = DstM.getOrInsertModuleFlagsMetadata();
case Module::AppendUnique: {
       MDNode *SrcValue = cast<MDNode>(SrcOp->getOperand(2));
       Elts.insert(DstValue->op_begin(), DstValue->op_end());
       Elts.insert(SrcValue->op_begin(), SrcValue->op_end());
 
       replaceDstValue(MDNode::get(DstM.getContext(),
                                   makeArrayRef(Elts.begin(), Elts.end())));
       break;
     }
+    case Module::MergeTargetID: {
+      StringRef DstTargetID = cast<MDString>(DstOp->getOperand(2))->getString();
+      StringRef SrcTargetID = cast<MDString>(SrcOp->getOperand(2))->getString();
+
+      // Check if source and target triple and cpu matches. An empty target ID
+      // represents a 'generic' cpu which can link with any other target ID.
+      StringRef DstTripleCPU = DstTargetID.split(':').first;
+      StringRef SrcTripleCPU = SrcTargetID.split(':').first;
+      if (!DstTargetID.empty() && !SrcTargetID.empty() &&
+          DstTripleCPU != SrcTripleCPU)
+        return stringErr("linking module flags '" + ID->getString() +
+                         "': IDs have conflicting values ('" + SrcTargetID +
+                         "' from '" + SrcM->getModuleIdentifier() + "' with '" +
+                         DstTargetID + "' from '" + DstM.getModuleIdentifier() +
+                         "'");
+
+      // Extract features from target ID. The first ':' delimits the
+      // "<triple>-<cpu>" portion from the features, which are then also
+      // delimited by ':'. Features are postfixed with '+' or '-'.
+      // Returns false if the format is invalid.
+      auto GetFeatures = [](StringRef TargetID,
+                            std::map<StringRef, bool> &Features) {
+        auto Splits = TargetID.split(':');
+        auto FeatureStr = Splits.second;
+        while (!FeatureStr.empty()) {
+          auto Splits = FeatureStr.split(':');
+          auto F = Splits.first;
+          auto Sign = F.back();
+          if (Sign != '+' && Sign != '-')
+            return false;
+          F = F.drop_back();
+          if (F.empty())
+            return false;
+          auto Loc = Features.find(F);
+          if (Loc != Features.end())
+            return false;
+          Features[F] = Sign == '+';
+          FeatureStr = Splits.second;
+        }
+        return true;
+      };
+      // Use std::map instead of StringMap to get the features in alphabetical
+      // order.
+      std::map<StringRef, bool> DstFeatures;
+      std::map<StringRef, bool> SrcFeatures;
+      // Diagnose target ID's whose formats are invalid.
+      if (!GetFeatures(DstTargetID, DstFeatures)) {
+        return stringErr("invalid module flag '" + ID->getString() +
+                         "': incorrect format ('" + DstTargetID + "' from '" +
+                         DstM.getModuleIdentifier() + "'");
+      }
+      if (!GetFeatures(SrcTargetID, SrcFeatures)) {
+        return stringErr("invalid module flag '" + ID->getString() +
+                         "': incorrect format ('" + SrcTargetID + "' from '" +
+                         SrcM->getModuleIdentifier() + "'");
+      }
+
+      // If destination and source target ID's both contain a feature but with
+      // different signs, they cannot be merged.
+      for (const auto &F : DstFeatures) {
+        auto Loc = SrcFeatures.find(F.first);
+        if (Loc != SrcFeatures.end() && Loc->second != F.second)
+          return stringErr("linking module flags '" + ID->getString() +
+                           "': IDs have conflicting values ('" + SrcTargetID +
+                           "' from '" + SrcM->getModuleIdentifier() +
+                           "' with '" + DstTargetID + "' from '" +
+                           DstM.getModuleIdentifier() + "'");
       }
 
+      // Merge features from source target ID into destination target ID.
+      for (const auto &F : SrcFeatures) {
+        auto Loc = DstFeatures.find(F.first);
+        if (Loc == DstFeatures.end()) {
+          DstFeatures[F.first] = F.second;
+        }
+      }
+
+      // Create a target ID containing new features merged from the source
+      // target ID.
+      std::string MergedTargetID =
+          DstTripleCPU.empty() ? SrcTripleCPU.str() : DstTripleCPU.str();
+      for (const auto &F : DstFeatures)
+        MergedTargetID =
+            MergedTargetID + ":" + F.first.str() + (F.second ? "+" : "-");
+
+      // Create the new module flag containing the merged target ID.
+      Metadata *FlagOps[] = {DstOp->getOperand(0), ID,
+                             MDString::get(DstM.getContext(), MergedTargetID)};
+      MDNode *Flag = MDNode::get(DstM.getContext(), FlagOps);
+      DstModFlags->setOperand(DstIndex, Flag);
+      Flags[ID].first = Flag;
+      break;
+    }
+    }
   }
 
   // Check all of the requirements.
   for (unsigned I = 0, E = Requirements.size(); I != E; ++I) {
     MDNode *Requirement = Requirements[I];
     MDString *Flag = cast<MDString>(Requirement->getOperand(0));
     Metadata *ReqValue = Requirement->getOperand(1);
 

llvm/test/Linker/Inputs/module-flags-target-id-src-default.ll

+; This file is used with module-flags-target-id-dst-*.ll
+
+!llvm.module.flags = !{ !0 }
+!0 = !{ i32 8, !"target-id", !"amdgcn-amd-amdhsa--gfx908" }

llvm/test/Linker/Inputs/module-flags-target-id-src-diff-cpu.ll

+; This file is used with module-flags-target-id-dst-*.ll
+
+!llvm.module.flags = !{ !0 }
+!0 = !{ i32 8, !"target-id", !"amdgcn-amd-amdhsa--gfx900" }

llvm/test/Linker/Inputs/module-flags-target-id-src-diff-triple.ll

+; This file is used with module-flags-target-id-dst-*.ll
+
+!llvm.module.flags = !{ !0 }
+!0 = !{ i32 8, !"target-id", !"amdgcn-amd-amdpal--gfx908" }

llvm/test/Linker/Inputs/module-flags-target-id-src-empty.ll

+; This file is used with module-flags-target-id-dst-*.ll
+
+!llvm.module.flags = !{ !0 }
+!0 = !{ i32 8, !"target-id", !"" }

llvm/test/Linker/Inputs/module-flags-target-id-src-invalid.ll

+; This file is used with module-flags-target-id-dst-*.ll
+
+; Invalid target id: feature must ends with +/-.
+!llvm.module.flags = !{ !0 }
+!0 = !{ i32 8, !"target-id", !"amdgcn-amd-amdhsa--gfx908:xnack" }

llvm/test/Linker/Inputs/module-flags-target-id-src-none.ll

+; This file is used with module-flags-target-id-dst-*.ll
+
+!llvm.module.flags = !{ !0 }
+!0 = !{ i32 1, !"foo", i32 37 }

llvm/test/Linker/Inputs/module-flags-target-id-src-sram-ecc-off-xnack-on.ll

+; This file is used with module-flags-target-id-dst-*.ll
+
+!llvm.module.flags = !{ !0 }
+!0 = !{ i32 8, !"target-id", !"amdgcn-amd-amdhsa--gfx908:sram-ecc-:xnack+" }

llvm/test/Linker/Inputs/module-flags-target-id-src-xnack-off.ll

+; This file is used with module-flags-target-id-dst-*.ll
+
+!llvm.module.flags = !{ !0 }
+!0 = !{ i32 8, !"target-id", !"amdgcn-amd-amdhsa--gfx908:xnack-" }

llvm/test/Linker/module-flags-target-id-dst-default.ll

+; RUN: llvm-link %s %p/Inputs/module-flags-target-id-src-default.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefixes=NOCHANGE,COMMON %s
+
+; RUN: llvm-link %s %p/Inputs/module-flags-target-id-src-empty.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefixes=NOCHANGE,COMMON %s
+
+; RUN: llvm-link %s %p/Inputs/module-flags-target-id-src-sram-ecc-off-xnack-on.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefixes=BOTH,COMMON %s
+
+; RUN: llvm-link %s %p/Inputs/module-flags-target-id-src-xnack-off.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefixes=XNACK,COMMON %s
+
+; RUN: not llvm-link %s %p/Inputs/module-flags-target-id-src-invalid.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefix=INVALID %s
+
+; RUN: not llvm-link %s %p/Inputs/module-flags-target-id-src-diff-triple.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefix=DIFFTRIPLE %s
+
+; RUN: not llvm-link %s %p/Inputs/module-flags-target-id-src-diff-cpu.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefix=DIFFCPU %s
+
+; RUN: not llvm-link %s %p/Inputs/module-flags-target-id-src-none.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefix=CONFLICT2 %s
+
+; Test target id module flags.
+
+; COMMON: !llvm.module.flags = !{!0}
+; NOCHANGE: !0 = !{i32 8, !"target-id", !"amdgcn-amd-amdhsa--gfx908"}
+; BOTH: !0 = !{i32 8, !"target-id", !"amdgcn-amd-amdhsa--gfx908:sram-ecc-:xnack+"}
+; XNACK: !0 = !{i32 8, !"target-id", !"amdgcn-amd-amdhsa--gfx908:xnack-"}
+
+; INVALID: error: invalid module flag 'target-id': incorrect format ('amdgcn-amd-amdhsa--gfx908:xnack'
+; DIFFTRIPLE: error: linking module flags 'target-id': IDs have conflicting values ('amdgcn-amd-amdpal--gfx908' from '{{.*}}' with 'amdgcn-amd-amdhsa--gfx908' from '{{.*}}'
+; DIFFCPU: error: linking module flags 'target-id': IDs have conflicting values ('amdgcn-amd-amdhsa--gfx900' from '{{.*}}' with 'amdgcn-amd-amdhsa--gfx908' from '{{.*}}'
+; CONFLICT2: error: cannot link '{{.*}}' which has target-id with '{{.*}}' which does not have target-id.
+
+!llvm.module.flags = !{ !0 }
+!0 = !{ i32 8, !"target-id", !"amdgcn-amd-amdhsa--gfx908" }

llvm/test/Linker/module-flags-target-id-dst-empty.ll

+; RUN: llvm-link %s %p/Inputs/module-flags-target-id-src-default.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefixes=DEFAULT,COMMON %s
+
+; RUN: llvm-link %s %p/Inputs/module-flags-target-id-src-empty.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefixes=EMPTY,COMMON %s
+
+; RUN: llvm-link %s %p/Inputs/module-flags-target-id-src-sram-ecc-off-xnack-on.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefixes=BOTH,COMMON %s
+
+; RUN: llvm-link %s %p/Inputs/module-flags-target-id-src-xnack-off.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefixes=XNACK,COMMON %s
+
+; RUN: not llvm-link %s %p/Inputs/module-flags-target-id-src-invalid.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefix=INVALID %s
+
+; RUN: llvm-link %s %p/Inputs/module-flags-target-id-src-diff-triple.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefixes=DIFFTRIPLE,COMMON %s
+
+; RUN: llvm-link %s %p/Inputs/module-flags-target-id-src-diff-cpu.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefixes=DIFFCPU,COMMON %s
+
+; RUN: not llvm-link %s %p/Inputs/module-flags-target-id-src-none.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefix=NONE %s
+
+; Test target id module flags.
+
+; COMMON: !llvm.module.flags = !{!0}
+; DEFAULT: !0 = !{i32 8, !"target-id", !"amdgcn-amd-amdhsa--gfx908"}
+; EMPTY: !0 = !{i32 8, !"target-id", !""}
+; BOTH: !0 = !{i32 8, !"target-id", !"amdgcn-amd-amdhsa--gfx908:sram-ecc-:xnack+"}
+; XNACK: !0 = !{i32 8, !"target-id", !"amdgcn-amd-amdhsa--gfx908:xnack-"}
+; DIFFTRIPLE: !0 = !{i32 8, !"target-id", !"amdgcn-amd-amdpal--gfx908"}
+; DIFFCPU: !0 = !{i32 8, !"target-id", !"amdgcn-amd-amdhsa--gfx900"}
+
+; INVALID: error: invalid module flag 'target-id': incorrect format ('amdgcn-amd-amdhsa--gfx908:xnack'
+; NONE: error: cannot link 'llvm-link' which has target-id with '{{.*}}' which does not have target-id
+
+!llvm.module.flags = !{ !0 }
+!0 = !{ i32 8, !"target-id", !"" }

llvm/test/Linker/module-flags-target-id-dst-none.ll

+; RUN: not llvm-link %s %p/Inputs/module-flags-target-id-src-default.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefix=CONFLICT %s
+
+; RUN: not llvm-link %s %p/Inputs/module-flags-target-id-src-empty.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefix=CONFLICT %s
+
+; RUN: not llvm-link %s %p/Inputs/module-flags-target-id-src-sram-ecc-off-xnack-on.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefix=CONFLICT %s
+
+; RUN: not llvm-link %s %p/Inputs/module-flags-target-id-src-xnack-off.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefix=CONFLICT %s
+
+; RUN: not llvm-link %s %p/Inputs/module-flags-target-id-src-invalid.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefix=CONFLICT %s
+
+; RUN: not llvm-link %s %p/Inputs/module-flags-target-id-src-diff-cpu.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefix=CONFLICT %s
+
+; RUN: llvm-link %s %p/Inputs/module-flags-target-id-src-none.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefix=NONE %s
+
+; Test target id module flags.
+
+; NONE: !llvm.module.flags = !{!0}
+; NONE: !0 = !{i32 1, !"foo", i32 37}
+
+; CONFLICT: error: cannot link '{{.*}}' which has target-id with '{{.*}}' which does not have target-id.
+
+!llvm.module.flags = !{ !0 }
+!0 = !{ i32 1, !"foo", i32 37 }

llvm/test/Linker/module-flags-target-id-dst-sram-ecc-off-xnack-on.ll

+; RUN: llvm-link %s %p/Inputs/module-flags-target-id-src-default.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefix=NOCHANGE %s
+
+; RUN: llvm-link %s %p/Inputs/module-flags-target-id-src-empty.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefixes=NOCHANGE %s
+
+; RUN: llvm-link %s %p/Inputs/module-flags-target-id-src-sram-ecc-off-xnack-on.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefix=NOCHANGE %s
+
+; RUN: not llvm-link %s %p/Inputs/module-flags-target-id-src-diff-triple.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefix=DIFFTRIPLE %s
+
+; RUN: not llvm-link %s %p/Inputs/module-flags-target-id-src-diff-cpu.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefix=DIFFCPU %s
+
+; RUN: not llvm-link %s %p/Inputs/module-flags-target-id-src-xnack-off.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefix=NOXNACK %s
+
+; RUN: not llvm-link %s %p/Inputs/module-flags-target-id-src-invalid.ll -S -o - \
+; RUN:  2>&1 | FileCheck -check-prefix=INVALID %s
+
+; Test target id module flags.
+
+; NOCHANGE: !llvm.module.flags = !{!0}
+; NOCHANGE: !0 = !{i32 8, !"target-id", !"amdgcn-amd-amdhsa--gfx908:sram-ecc-:xnack+"}
+
+; DIFFTRIPLE: error: linking module flags 'target-id': IDs have conflicting values ('amdgcn-amd-amdpal--gfx908' from '{{.*}}' with 'amdgcn-amd-amdhsa--gfx908:sram-ecc-:xnack+' from '{{.*}}'
+; DIFFCPU: error: linking module flags 'target-id': IDs have conflicting values ('amdgcn-amd-amdhsa--gfx900' from '{{.*}}' with 'amdgcn-amd-amdhsa--gfx908:sram-ecc-:xnack+' from '{{.*}}'
+; NOXNACK: error: linking module flags 'target-id': IDs have conflicting values ('amdgcn-amd-amdhsa--gfx908:xnack-' from '{{.*}}' with 'amdgcn-amd-amdhsa--gfx908:sram-ecc-:xnack+' from '{{.*}}'
+
+; INVALID: error: invalid module flag 'target-id': incorrect format ('amdgcn-amd-amdhsa--gfx908:xnack'
+
+!llvm.module.flags = !{ !0 }
+!0 = !{ i32 8, !"target-id", !"amdgcn-amd-amdhsa--gfx908:sram-ecc-:xnack+" }

llvm/test/Verifier/module-flags-target-id-invalid-key.ll

+; RUN: not opt -verify %s 2>&1 | FileCheck %s
+
+; CHECK: Invalid key for 'MergeTargetID' module flag (expected 'target-id')
+
+!llvm.module.flags = !{ !0 }
+
+!0 = !{ i32 8, !"foo", !"amdgcn-amd-amdhsa-gfx908" }

llvm/test/Verifier/module-flags-target-id-invalid-value.ll

+; RUN: not opt -verify %s 2>&1 | FileCheck %s
+
+; CHECK: invalid value for 'MergeTargetID' module flag (expected string)
+
+!llvm.module.flags = !{ !0 }
+
+!0 = !{ i32 8, !"target-id", i32 37 }