<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in odr-lambda-2.ll</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>2c864551 - [DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Linker/Inputs/odr-lambda-2.ll#2c864551</link>
        <description>[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.In order to set breakpoints on labels and list source code aroundlabels, we need collect debug information for labels, i.e., labelname, the function label belong, line number in the file, and theaddress label located. In order to keep these information in LLVMIR and to allow backend to generate debug information correctly.We create a new kind of metadata for labels, DILabel. The formatof DILabel is!DILabel(scope: !1, name: &quot;foo&quot;, file: !2, line: 3)We hope to keep debug information as much as possible even thecode is optimized. So, we create a new kind of intrinsic for labelmetadata to avoid the metadata is eliminated with basic block.The intrinsic will keep existing if we keep it from optimized out.The format of the intrinsic isllvm.dbg.label(metadata !1)It has only one argument, that is the DILabel metadata. Theintrinsic will follow the label immediately. Backend could get thelabel metadata through the intrinsic&apos;s parameter.We also create DIBuilder API for labels to be used by Frontend.Frontend could use createLabel() to allocate DILabel objects, and useinsertLabel() to insert llvm.dbg.label intrinsic in LLVM IR.Differential Revision: https://reviews.llvm.org/D45024Patch by Hsiangkai Wang.llvm-svn: 331841

            List of files:
            /llvm-project-15.0.7/llvm/test/Linker/Inputs/odr-lambda-2.ll</description>
        <pubDate>Wed, 09 May 2018 02:40:45 +0000</pubDate>
        <dc:creator>Shiva Chen &lt;shiva0217@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>5a82f0a4 - Verifier: Ignore CUs pulled in by ODR-uniqued types.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Linker/Inputs/odr-lambda-2.ll#5a82f0a4</link>
        <description>Verifier: Ignore CUs pulled in by ODR-uniqued types.When more than one Module is imported into the same context, such as duringan LTO build before linking the modules, ODR type uniquing may cause typesto point to a different CU. This check does not make sense in this case.This fixes the error reported in PR34944.https://bugs.llvm.org/show_bug.cgi?id=34944rdar://problem/34940685This reapplies a cleaner implementation of r316049.llvm-svn: 316052

            List of files:
            /llvm-project-15.0.7/llvm/test/Linker/Inputs/odr-lambda-2.ll</description>
        <pubDate>Wed, 18 Oct 2017 01:11:01 +0000</pubDate>
        <dc:creator>Adrian Prantl &lt;aprantl@apple.com&gt;</dc:creator>
    </item>
<item>
        <title>f9a1cf6d - Verifier: Ignore CUs pulled in by ODR-uniqued types.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Linker/Inputs/odr-lambda-2.ll#f9a1cf6d</link>
        <description>Verifier: Ignore CUs pulled in by ODR-uniqued types.When more than one Module is imported into the same context, such as duringan LTO build before linking the modules, ODR type uniquing may cause typesto point to a different CU. This check does not make sense in this case.This fixes the error reported in PR34944.https://bugs.llvm.org/show_bug.cgi?id=34944rdar://problem/34940685llvm-svn: 316049

            List of files:
            /llvm-project-15.0.7/llvm/test/Linker/Inputs/odr-lambda-2.ll</description>
        <pubDate>Wed, 18 Oct 2017 00:49:31 +0000</pubDate>
        <dc:creator>Adrian Prantl &lt;aprantl@apple.com&gt;</dc:creator>
    </item>
</channel>
</rss>
