<?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 cmpxchg.3.6.ll</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>2a661cd0 - [opaque pointer type] Encode the pointee type in the bitcode for &apos;cmpxchg&apos;</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Bitcode/cmpxchg.3.6.ll#2a661cd0</link>
        <description>[opaque pointer type] Encode the pointee type in the bitcode for &apos;cmpxchg&apos;As a space optimization, this instruction would just encode the pointertype of the first operand and use the knowledge that the second andthird operands would be of the pointee type of the first. When typedpointers go away, this assumption will no longer be available - soencode the type of the second operand explicitly and rely on that forthe third.Test case added to demonstrate the backwards compatibility concern,which only comes up when the definition of the second operand comesafter the use (hence the weird basic block sequence) - at which pointthe type needs to be explicitly encoded in the bitcode and the recordlength changes to accommodate this.llvm-svn: 235966

            List of files:
            /llvm-project-15.0.7/llvm/test/Bitcode/cmpxchg.3.6.ll</description>
        <pubDate>Tue, 28 Apr 2015 04:30:29 +0000</pubDate>
        <dc:creator>David Blaikie &lt;dblaikie@gmail.com&gt;</dc:creator>
    </item>
</channel>
</rss>
