Add !associated metadata.

[eugenis]

Summary

This is an ELF-specific thing that adds SHF_LINK_ORDER to the global's section
pointing to the metadata argument's section. The effect of that is a reverse dependency
between sections for the linker GC.

!associated does not change the behavior of global-dce. The global
may also need to be added to llvm.compiler.used.

Since SHF_LINK_ORDER is per-section, !associated effectively enables
fdata-sections for the affected globals, the same as comdats do

[mehdi_amini]

Can you clarify on the use case and why llvm.compiler.used isn't enough?

[mehdi_amini]

test/ThinLTO/X86/lazyload_metadata.ll

19 ↗

(On Diff #85658)

I don't understand where this is coming from?

[eugenis]

See https://reviews.llvm.org/D28481 for the previous attempt at this.

In short, ASan emits "metadata" globals for each original global, and needs them to be alive as long as the corresponding original global is. We can not put a reference to the "metadata" global into the original global, because that would kill .bss (among other things).

The only part of this CL that we really need is the one that emits SHF_ASSOCIATED for "metadata" globals. The GlobalDCE part mirrors the linker handling of SHF_ASSOCIATED. As an alternative, we could add all "metadata" globals to llvm.compiler.used, but that would suppress some optimizations.

See this discussion of SHF_ASSOCIATED:
https://groups.google.com/d/msg/generic-abi/_CbBM6T6WeM/LZnqx1KZAQAJ

test/ThinLTO/X86/lazyload_metadata.ll

19 ↗

(On Diff #85658)

I assume, because of the extra fixed metadata kind.

[mehdi_amini]

Can you articulate the reasons not to you llvm.compiler_used?

[majnemer]

This sounds _a lot_ like COMDATs, could you use those?

[mehdi_amini]

I mean the specific optimizations that won't happen that motivate not using llvm.compiler.used.

[eugenis]

In D29104#655649, @majnemer wrote:

This sounds _a lot_ like COMDATs, could you use those?

Been there, see the generic-abi ml discussion.

[eugenis]

In D29104#655651, @mehdi_amini wrote:

I mean the specific optimizations that won't happen that motivate not using llvm.compiler.used.

I'm not sure. Perhaps, link time devirtualization? Without this, ASan would have to add every single global to llvm.compiler.used, which would make globaldce not do anything at all. If anything, it is bad for the object file size.

The real reason is w/o the GlobalDCE change !associated has strange semantics - it protects a global from linker GC, but only if said global survives compiler GC. I don't see how that is useful.

[majnemer]

In D29104#655652, @eugenis wrote:

In D29104#655649, @majnemer wrote:

This sounds _a lot_ like COMDATs, could you use those?

Been there, see the generic-abi ml discussion.

I can't find it, could you please link it?

[eugenis]

https://groups.google.com/d/msg/generic-abi/_CbBM6T6WeM/LZnqx1KZAQAJ

[mehdi_amini]

In D29104#655669, @eugenis wrote:

In D29104#655651, @mehdi_amini wrote:

I mean the specific optimizations that won't happen that motivate not using llvm.compiler.used.

I'm not sure. Perhaps, link time devirtualization? Without this, ASan would have to add every single global to llvm.compiler.used, which would make globaldce not do anything at all.

It'll still operate on every functions. And this is what happens on Darwin today.

If anything, it is bad for the object file size.

Linker will garbage collect.

The real reason is w/o the GlobalDCE change !associated has strange semantics - it protects a global from linker GC, but only if said global survives compiler GC. I don't see how that is useful.

I'm not convinced at all by the !associated at this point, in particular I haven't seen anything it does which is different from what is done on Darwin.

[eugenis]

In D29104#655685, @mehdi_amini wrote:

In D29104#655669, @eugenis wrote:

In D29104#655651, @mehdi_amini wrote:

I mean the specific optimizations that won't happen that motivate not using llvm.compiler.used.

I'm not sure. Perhaps, link time devirtualization? Without this, ASan would have to add every single global to llvm.compiler.used, which would make globaldce not do anything at all.

It'll still operate on every functions. And this is what happens on Darwin today.

Yes, and it works fine. But on Linux we can do better.

Isn't it possible that GC-ing of virtual tables would kill class methods, which can in turn kill more virtual tables and allow devirtualizing of more call sites?

If anything, it is bad for the object file size.

Linker will garbage collect.

Object file size matters, too.

The real reason is w/o the GlobalDCE change !associated has strange semantics - it protects a global from linker GC, but only if said global survives compiler GC. I don't see how that is useful.

I'm not convinced at all by the !associated at this point, in particular I haven't seen anything it does which is different from what is done on Darwin.

Darwin is not a problem here. ELF is.
On Darwin, ASan uses the "live_support" linker hack:
https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/Instrumentation/AddressSanitizer.cpp#L1680
SHF_ASSOCIATED is the proposed ELF implementation of roughly the same concept. We need a way to represent it in the IR.

[mehdi_amini]

In D29104#655699, @eugenis wrote:

In D29104#655685, @mehdi_amini wrote:

In D29104#655669, @eugenis wrote:

In D29104#655651, @mehdi_amini wrote:

I mean the specific optimizations that won't happen that motivate not using llvm.compiler.used.

I'm not sure. Perhaps, link time devirtualization? Without this, ASan would have to add every single global to llvm.compiler.used, which would make globaldce not do anything at all.

It'll still operate on every functions. And this is what happens on Darwin today.

Yes, and it works fine. But on Linux we can do better.

I'm missing what is platform specific in this?

Isn't it possible that GC-ing of virtual tables would kill class methods, which can in turn kill more virtual tables and allow devirtualizing of more call sites?

Possible, we'll have to consider the benefit of "advanced optimizations" in the context of ASAN builds though, and balanced this with the cost.

If anything, it is bad for the object file size.

Linker will garbage collect.

Object file size matters, too.

I'll ask to see the numbers before moving forward with this motivation.

The real reason is w/o the GlobalDCE change !associated has strange semantics - it protects a global from linker GC, but only if said global survives compiler GC. I don't see how that is useful.

I'm not convinced at all by the !associated at this point, in particular I haven't seen anything it does which is different from what is done on Darwin.

Darwin is not a problem here. ELF is.
On Darwin, ASan uses the "live_support" linker hack:
https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/Instrumentation/AddressSanitizer.cpp#L1680

Sure, I know about this: https://github.com/llvm-mirror/llvm/commit/090f75dc839cbe1d94c8445bf8fabd0f19309f25

SHF_ASSOCIATED is the proposed ELF implementation of roughly the same concept. We need a way to represent it in the IR.

Sure, I get that, but what is fundamentally different between the Darwin live_support section and SHF_ASSOCIATED?
This is likely the main piece of information that I'm missing right now.

I also don't think that adding metadata that are "correctness related" is a good thing in general.

[mehdi_amini]

I also don't think that adding metadata that are "correctness related" is a good thing in general.

And what I mean by that is that a "good" scheme should allow to ignore the metadata and the metadata can enable more optimization for the passes that understands it,

[eugenis]

I also don't think that adding metadata that are "correctness related" is a good thing in general.

Yeah. This could be a global flag. But we already have !type metadata which is correctness related.

OK. We can start with !associated that does not affect DCE. Its only effect would be setting SHF_ASSOCIATED on the ELF section. ASan would add all "metadata" globals to llvm.compiler.used.

[eugenis]

I've removed all global-dce changes and, according to D29590, added an argument to the metadata that gives the target of SHF_LINK_ORDER.
PTAL.

[mehdi_amini]

Can this metadata be freely dropped? Clarify this in LangRef please.

docs/LangRef.rst

5110 ↗

(On Diff #88834)

80 cols.

[eugenis]

In D29104#680016, @mehdi_amini wrote:

Can this metadata be freely dropped? Clarify this in LangRef please.

It can not. Added a note in LangRef.

[mehdi_amini]

docs/LangRef.rst

5112 ↗

(On Diff #88955)

I don't think this is an OK property of metadata.
Have you look for another representation that would not have this constraint?

[eugenis]

docs/LangRef.rst

5112 ↗

(On Diff #88955)

It does not seem to be that bad. After all, !type and !absolute_symbol already have that property, they just don't document it.

[eugenis]

docs/LangRef.rst

5112 ↗

(On Diff #88955)

How about now?
Under this list of conditions the metadata can be discarded, which will make the global non-discardable.

[mehdi_amini]

docs/LangRef.rst

5112 ↗

(On Diff #88955)

From LangRef:

A transformation is required to drop any metadata attachment that it does not know or know it can’t preserve. Currently there is an exception for metadata attachment to globals for !type and !absolute_symbol which can’t be unconditionally dropped unless the global is itself deleted.

[eugenis]

docs/LangRef.rst

5112 ↗

(On Diff #88955)

Ah thanks, I was expecting to find this in the individual metadata type's sections.

[mehdi_amini]

docs/LangRef.rst

5117 ↗

(On Diff #88967)

From the sentence this list is just "guidelines", correct? Is it still "valid" to use the associated MD without a section? In different comdats?

[mehdi_amini]

The IR part (LangRef) seems OK to me.
The ELF part is out of my scope, if rafael or pcc already checked it, that's fine.

docs/LangRef.rst

5113 ↗

(On Diff #88967)

colon?
Also, since it seems to be advisory and not mandatory I wouldn't use "must" but "may".

[pcc]

include/llvm/MC/MCSectionELF.h

95 ↗

(On Diff #88974)

I don't quite follow why you need to change this from storing a section to a symbol.

lib/CodeGen/TargetLoweringObjectFileImpl.cpp

220 ↗

(On Diff #88974)

What if GO is null? (This could happen if we RAUW the GlobalObject with some other constant.)

I think the right behavior in that case would be to return null from this function.

[eugenis]

include/llvm/MC/MCSectionELF.h

95 ↗

(On Diff #88974)

Because we need the symbol name when printing textual assembly.

[pcc]

include/llvm/MC/MCSectionELF.h

95 ↗

(On Diff #88974)

I see. Could you separate the printer fix out into a separate change please?

lib/CodeGen/TargetLoweringObjectFileImpl.cpp

370 ↗

(On Diff #88984)

Remove this line.

lib/MC/MCSectionELF.cpp

157 ↗

(On Diff #88984)

Would AssociatedSymbol ever be null?

[eugenis]

include/llvm/MC/MCSectionELF.h

95 ↗

(On Diff #88974)

See D30129

[pcc]

Can you please refresh this change?

[eugenis]

done, PTAL

[pcc]

lib/CodeGen/TargetLoweringObjectFileImpl.cpp

243–244 ↗

(On Diff #89003)

I think you need to make sure AssociatedSymbol is non-null before setting the flag. Please also add a negative test for a non-GlobalObject constant.

366–367 ↗

(On Diff #89003)

Same here.

[pcc]

LGTM

llvm/trunk/docs/LangRef.rst

.. code-block:: llvm
    !0 = !{!"magic ptr"}
    !1 = !{!"other ptr"}
 
 '``type``' Metadata
 ^^^^^^^^^^^^^^^^^^^
 
 See :doc:`TypeMetadata`.
 
+'``associated``' Metadata
+^^^^^^^^^^^^^^^^^^^
+
+The ``associated`` metadata may be attached to a global object
+declaration with a single argument that references another global object.
+
+This metadata prevents discarding of the global object in linker GC
+unless the referenced object is also discarded. The linker support for
+this feature is spotty. For best compatibility, globals carrying this
+metadata may also:
+
+- Be in a comdat with the referenced global.
+- Be in @llvm.compiler.used.
+- Have an explicit section with a name which is a valid C identifier.
+
+It does not have any effect on non-ELF targets.
+
+Example:
+
+.. code-block:: llvm
+    $a = comdat any
+    @a = global i32 1, comdat $a
+    @b = internal global i32 2, comdat $a, section "abc", !associated !0
+    !0 = !{i32* @a}
+
 
 Module Flags Metadata
 =====================
 
 Information about the module as a whole is difficult to convey to LLVM's
 subsystems. The LLVM IR isn't sufficient to transmit this information.
 The ``llvm.module.flags`` named metadata exists in order to facilitate
 this. These flags are in the form of key / value pairs --- much like a

llvm/trunk/include/llvm/IR/LLVMContext.h

enum {
     MD_make_implicit = 14,            // "make.implicit"
     MD_unpredictable = 15,            // "unpredictable"
     MD_invariant_group = 16,          // "invariant.group"
     MD_align = 17,                    // "align"
     MD_loop = 18,                     // "llvm.loop"
     MD_type = 19,                     // "type"
     MD_section_prefix = 20,           // "section_prefix"
     MD_absolute_symbol = 21,          // "absolute_symbol"
+    MD_associated = 22,               // "associated"
   };
 
   /// Known operand bundle tag IDs, which always have the same value.  All
   /// operand bundle tags that LLVM has special knowledge of are listed here.
   /// Additionally, this scheme allows LLVM to efficiently check for specific
   /// operand bundle tags without comparing strings.
   enum {
     OB_deopt = 0,         // "deopt"

llvm/trunk/lib/CodeGen/TargetLoweringObjectFileImpl.cpp

static const Comdat *getELFComdat(const GlobalValue *GV) {
 
   if (C->getSelectionKind() != Comdat::Any)
     report_fatal_error("ELF COMDATs only support SelectionKind::Any, '" +
                        C->getName() + "' cannot be lowered.");
 
   return C;
 }
 
+static const MCSymbolELF *getAssociatedSymbol(const GlobalObject *GO,
+                                              const TargetMachine &TM) {
+  MDNode *MD = GO->getMetadata(LLVMContext::MD_associated);
+  if (!MD)
+    return nullptr;
+
+  auto *VM = dyn_cast<ValueAsMetadata>(MD->getOperand(0));
+  if (!VM)
+    report_fatal_error("MD_associated operand is not ValueAsMetadata");
+
+  GlobalObject *OtherGO = dyn_cast<GlobalObject>(VM->getValue());
+  return OtherGO ? dyn_cast<MCSymbolELF>(TM.getSymbol(OtherGO)) : nullptr;
+}
+
 MCSection *TargetLoweringObjectFileELF::getExplicitSectionGlobal(
     const GlobalObject *GO, SectionKind Kind, const TargetMachine &TM) const {
   StringRef SectionName = GO->getSection();
 
   // Infer section flags from the section name if we can.
   Kind = getELFKindForNamedSection(SectionName, Kind);
 
   StringRef Group = "";
   unsigned Flags = getELFSectionFlags(Kind);
   if (const Comdat *C = getELFComdat(GO)) {
     Group = C->getName();
     Flags |= ELF::SHF_GROUP;
   }
-  return getContext().getELFSection(SectionName,
-                                    getELFSectionType(SectionName, Kind), Flags,
-                                    /*EntrySize=*/0, Group);
+
+  // A section can have at most one associated section. Put each global with
+  // MD_associated in a unique section.
+  unsigned UniqueID = MCContext::GenericSectionID;
+  const MCSymbolELF *AssociatedSymbol = getAssociatedSymbol(GO, TM);
+  if (AssociatedSymbol) {
+    UniqueID = NextUniqueID++;
+    Flags |= ELF::SHF_LINK_ORDER;
+  }
+
+  MCSectionELF *Section = getContext().getELFSection(
+      SectionName, getELFSectionType(SectionName, Kind), Flags,
+      /*EntrySize=*/0, Group, UniqueID, AssociatedSymbol);
+  // Make sure that we did not get some other section with incompatible sh_link.
+  // This should not be possible due to UniqueID code above.
+  assert(Section->getAssociatedSymbol() == AssociatedSymbol);
+  return Section;
 }
 
 /// Return the section prefix name used by options FunctionsSections and
 /// DataSections.
 static StringRef getSectionPrefixForGlobal(SectionKind Kind) {
   if (Kind.isText())
     return ".text";
   if (Kind.isReadOnly())
     return ".rodata";
   if (Kind.isBSS())
     return ".bss";
   if (Kind.isThreadData())
     return ".tdata";
   if (Kind.isThreadBSS())
     return ".tbss";
   if (Kind.isData())
     return ".data";
   assert(Kind.isReadOnlyWithRel() && "Unknown section kind");
   return ".data.rel.ro";
 }
 
-static MCSectionELF *
-selectELFSectionForGlobal(MCContext &Ctx, const GlobalObject *GO,
-                          SectionKind Kind, Mangler &Mang,
-                          const TargetMachine &TM, bool EmitUniqueSection,
-                          unsigned Flags, unsigned *NextUniqueID) {
+static MCSectionELF *selectELFSectionForGlobal(
+    MCContext &Ctx, const GlobalObject *GO, SectionKind Kind, Mangler &Mang,
+    const TargetMachine &TM, bool EmitUniqueSection, unsigned Flags,
+    unsigned *NextUniqueID, const MCSymbolELF *AssociatedSymbol) {
   unsigned EntrySize = 0;
   if (Kind.isMergeableCString()) {
     if (Kind.isMergeable2ByteCString()) {
       EntrySize = 2;
     } else if (Kind.isMergeable4ByteCString()) {
       EntrySize = 4;
     } else {
       EntrySize = 1;
static MCSectionELF *selectELFSectionForGlobal(
   if (EmitUniqueSection && !UniqueSectionNames) {
     UniqueID = *NextUniqueID;
     (*NextUniqueID)++;
   }
   // Use 0 as the unique ID for execute-only text
   if (Kind.isExecuteOnly())
     UniqueID = 0;
   return Ctx.getELFSection(Name, getELFSectionType(Name, Kind), Flags,
-                           EntrySize, Group, UniqueID);
+                           EntrySize, Group, UniqueID, AssociatedSymbol);
 }
 
 MCSection *TargetLoweringObjectFileELF::SelectSectionForGlobal(
     const GlobalObject *GO, SectionKind Kind, const TargetMachine &TM) const {
   unsigned Flags = getELFSectionFlags(Kind);
 
   // If we have -ffunction-section or -fdata-section then we should emit the
   // global value to a uniqued section specifically for it.
   bool EmitUniqueSection = false;
   if (!(Flags & ELF::SHF_MERGE) && !Kind.isCommon()) {
     if (Kind.isText())
       EmitUniqueSection = TM.getFunctionSections();
     else
       EmitUniqueSection = TM.getDataSections();
   }
   EmitUniqueSection |= GO->hasComdat();
 
-  return selectELFSectionForGlobal(getContext(), GO, Kind, getMangler(), TM,
-                                   EmitUniqueSection, Flags, &NextUniqueID);
+  const MCSymbolELF *AssociatedSymbol = getAssociatedSymbol(GO, TM);
+  if (AssociatedSymbol) {
+    EmitUniqueSection = true;
+    Flags |= ELF::SHF_LINK_ORDER;
+  }
+
+  MCSectionELF *Section = selectELFSectionForGlobal(
+      getContext(), GO, Kind, getMangler(), TM, EmitUniqueSection, Flags,
+      &NextUniqueID, AssociatedSymbol);
+  assert(Section->getAssociatedSymbol() == AssociatedSymbol);
+  return Section;
 }
 
 MCSection *TargetLoweringObjectFileELF::getSectionForJumpTable(
     const Function &F, const TargetMachine &TM) const {
   // If the function can be removed, produce a unique section so that
   // the table doesn't prevent the removal.
   const Comdat *C = F.getComdat();
   bool EmitUniqueSection = TM.getFunctionSections() || C;
   if (!EmitUniqueSection)
     return ReadOnlySection;
 
   return selectELFSectionForGlobal(getContext(), &F, SectionKind::getReadOnly(),
-                                   getMangler(), TM, EmitUniqueSection, ELF::SHF_ALLOC,
-                                   &NextUniqueID);
+                                   getMangler(), TM, EmitUniqueSection,
+                                   ELF::SHF_ALLOC, &NextUniqueID,
+                                   /* AssociatedSymbol */ nullptr);
 }
 
 bool TargetLoweringObjectFileELF::shouldPutJumpTableInFunctionSection(
     bool UsesLabelDifference, const Function &F) const {
   // We can always create relative relocations, so use another section
   // that can be marked non-executable.
   return false;
 }

llvm/trunk/lib/IR/LLVMContext.cpp

std::pair<unsigned, StringRef> MDKinds[] = {
     {MD_make_implicit, "make.implicit"},
     {MD_unpredictable, "unpredictable"},
     {MD_invariant_group, "invariant.group"},
     {MD_align, "align"},
     {MD_loop, "llvm.loop"},
     {MD_type, "type"},
     {MD_section_prefix, "section_prefix"},
     {MD_absolute_symbol, "absolute_symbol"},
+    {MD_associated, "associated"},
   };
 
   for (auto &MDKind : MDKinds) {
     unsigned ID = getMDKindID(MDKind.second);
     assert(ID == MDKind.first && "metadata kind id drifted");
     (void)ID;
   }
 

llvm/trunk/test/CodeGen/X86/elf-associated.ll

+; RUN: llc -data-sections=1 -mtriple x86_64-pc-linux-gnu < %s | FileCheck %s
+; RUN: llc -data-sections=0 -mtriple x86_64-pc-linux-gnu < %s | FileCheck %s
+
+@a = global i32 1
+@b = global i32 2, !associated !0
+!0 = !{i32* @a}
+; CHECK-DAG: .section .data.b,"awm",@progbits,a
+
+; Loop is OK. Also, normally -data-sections=0 would place @c and @d in the same section. !associated prevents that.
+@c = global i32 2, !associated !2
+@d = global i32 2, !associated !1
+!1 = !{i32* @c}
+!2 = !{i32* @d}
+; CHECK-DAG: .section .data.c,"awm",@progbits,d
+; CHECK-DAG: .section .data.d,"awm",@progbits,c
+
+; BSS is OK.
+@e = global i32 0
+@f = global i32 0, !associated !3
+@g = global i32 1, !associated !3
+!3 = !{i32* @e}
+; CHECK-DAG: .section .bss.f,"awm",@nobits,e
+; CHECK-DAG: .section .data.g,"awm",@progbits,e
+
+; Explicit sections.
+@h = global i32 1, section "aaa"
+@i = global i32 1, section "bbb", !associated !4
+@j = global i32 1, section "bbb", !associated !4
+@k = global i32 1, !associated !4
+!4 = !{i32* @h}
+; CHECK-DAG: .section aaa,"aw",@progbits
+; CHECK-DAG: .section bbb,"awm",@progbits,h,unique,1
+; CHECK-DAG: .section bbb,"awm",@progbits,h,unique,2
+; CHECK-DAG: .section .data.k,"awm",@progbits,h
+
+; Non-GlobalObject metadata.
+@l = global i32 1, section "ccc", !associated !5
+!5 = !{i32* null}
+; CHECK-DAG: .section ccc,"aw",@progbits

llvm/trunk/test/ThinLTO/X86/lazyload_metadata.ll

 ; Do setup work for all below tests: generate bitcode and combined index
 ; RUN: opt -module-summary %s -o %t.bc -bitcode-mdindex-threshold=0
 ; RUN: opt -module-summary %p/Inputs/lazyload_metadata.ll -o %t2.bc -bitcode-mdindex-threshold=0
 ; RUN: llvm-lto -thinlto-action=thinlink -o %t3.bc %t.bc %t2.bc
 ; REQUIRES: asserts
 
 ; Check that importing @globalfunc1 does not trigger loading all the global
 ; metadata for @globalfunc2 and @globalfunc3
 
 ; RUN: llvm-lto -thinlto-action=import %t2.bc -thinlto-index=%t3.bc \
 ; RUN:          -o /dev/null -stats \
 ; RUN:  2>&1 | FileCheck %s -check-prefix=LAZY
-; LAZY: 49 bitcode-reader  - Number of Metadata records loaded
+; LAZY: 51 bitcode-reader  - Number of Metadata records loaded
 ; LAZY: 2 bitcode-reader  - Number of MDStrings loaded
 
 ; RUN: llvm-lto -thinlto-action=import %t2.bc -thinlto-index=%t3.bc \
 ; RUN:          -o /dev/null -disable-ondemand-mds-loading -stats \
 ; RUN:  2>&1 | FileCheck %s -check-prefix=NOTLAZY
-; NOTLAZY: 58 bitcode-reader  - Number of Metadata records loaded
+; NOTLAZY: 60 bitcode-reader  - Number of Metadata records loaded
 ; NOTLAZY: 7 bitcode-reader  - Number of MDStrings loaded
 
 
 target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-apple-macosx10.11.0"
 
 define void @globalfunc1(i32 %arg) {
   %x = call i1 @llvm.type.test(i8* undef, metadata !"typeid1")

 !1 = !{!2, !3, !4, !5, !6, !7, !8, !9}
 !2 = !{!"Hello World"}
 !3 = !{!"3"}
 !4 = !{!"4"}
 !5 = !{!"5"}
 !6 = !{!9}
 !7 = !{!"7"}
 !8 = !{!"8"}
-!9 = !{!6}
+!9 = !{!6}