<?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 weak2.ll</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>23af6484 - [opaque pointer type] Add textual IR support for explicit type parameter to the call instruction</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/ARM/weak2.ll#23af6484</link>
        <description>[opaque pointer type] Add textual IR support for explicit type parameter to the call instructionSee r230786 and r230794 for similar changes to gep and loadrespectively.Call is a bit different because it often doesn&apos;t have a single explicittype - usually the type is deduced from the arguments, and just thereturn type is explicit. In those cases there&apos;s no need to change theIR.When that&apos;s not the case, the IR usually contains the pointer type ofthe first operand - but since typed pointers are going away, thatrepresentation is insufficient so I&apos;m just stripping the &quot;pointerness&quot;of the explicit type away.This does make the IR a bit weird - it /sort of/ reads like the type ofthe first operand: &quot;call void () %x(&quot; but %x is actually of type &quot;void()*&quot; and will eventually be just of type &quot;ptr&quot;. But this seems not toobad and I don&apos;t think it would benefit from repeating the type(&quot;void (), void () * %x(&quot; and then eventually &quot;void (), ptr %x(&quot;) as hasbeen done with gep and load.This also has a side benefit: since the explicit type is no longer apointer, there&apos;s no ambiguity between an explicit type and a functionthat returns a function pointer. Previously this case needed an explicittype (eg: a function returning a void() function was written as&quot;call void () () * @x(&quot; rather than &quot;call void () * @x(&quot; because of theambiguity between a function returning a pointer to a void() functionand a function returning void).No ambiguity means even function pointer return types can just bewritten alone, without writing the whole function&apos;s type.This leaves /only/ the varargs case where the explicit type is required.Given the special type syntax in call instructions, the regex-fu usedfor migration was a bit more involved in its own unique way (as everyone of these is) so here it is. Use it in conjunction with the apply.shscript and associated find/xargs commands I&apos;ve provided in rr230786 tomigrate your out of tree tests. Do let me know if any of this doesn&apos;tcover your cases &amp; we can iterate on a more general script/regexes tohelp others with out of tree tests.About 9 test cases couldn&apos;t be automatically migrated - half of thosewere functions returning function pointers, where I just had to manuallydelete the function argument types now that we didn&apos;t need an explicitfunction type there. The other half were typedefs of function types usedin calls - just had to manually drop the * from those.import fileinputimport sysimport repat = re.compile(r&apos;((?:=|:|^|\s)call\s(?:[^@]*?))(\s*$|\s*(?:(?:\[\[[a-zA-Z0-9_]+\]\]|[@%](?:(&quot;)?[\\\?@a-zA-Z0-9_.]*?(?(3)&quot;|)|{{.*}}))(?:\(|$)|undef|inttoptr|bitcast|null|asm).*$)&apos;)addrspace_end = re.compile(r&quot;addrspace\(\d+\)\s*\*$&quot;)func_end = re.compile(&quot;(?:void.*|\)\s*)\*$&quot;)def conv(match, line):  if not match or re.search(addrspace_end, match.group(1)) or not re.search(func_end, match.group(1)):    return line  return line[:match.start()] + match.group(1)[:match.group(1).rfind(&apos;*&apos;)].rstrip() + match.group(2) + line[match.end():]for line in sys.stdin:  sys.stdout.write(conv(re.search(pat, line), line))llvm-svn: 235145

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/ARM/weak2.ll</description>
        <pubDate>Thu, 16 Apr 2015 23:24:18 +0000</pubDate>
        <dc:creator>David Blaikie &lt;dblaikie@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>7258735f - ARM: fixup more tests to specify the target more explicitly</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/ARM/weak2.ll#7258735f</link>
        <description>ARM: fixup more tests to specify the target more explicitlyThis changes the tests that were targeting ARM EABI to explicitly specify theenvironment rather than relying on the default.  This breaks with the newWindows on ARM support when running the tests on Windows where the defaultenvironment is no longer EABI.Take the opportunity to avoid a pointless redirect (helps when trying to debugwith providing a command line invocation which can be copy and pasted) andremoving a few greps in favour of FileCheck.llvm-svn: 205541

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/ARM/weak2.ll</description>
        <pubDate>Thu, 03 Apr 2014 16:01:44 +0000</pubDate>
        <dc:creator>Saleem Abdulrasool &lt;compnerd@compnerd.org&gt;</dc:creator>
    </item>
<item>
        <title>c8054d90 - Eliminate more uses of llvm-as and llvm-dis.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/ARM/weak2.ll#c8054d90</link>
        <description>Eliminate more uses of llvm-as and llvm-dis.llvm-svn: 81293

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/ARM/weak2.ll</description>
        <pubDate>Wed, 09 Sep 2009 00:09:15 +0000</pubDate>
        <dc:creator>Dan Gohman &lt;gohman@apple.com&gt;</dc:creator>
    </item>
<item>
        <title>4ae9425b - remember to emit weak reference in one more case.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/ARM/weak2.ll#4ae9425b</link>
        <description>remember to emit weak reference in one more case.llvm-svn: 36438

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/ARM/weak2.ll</description>
        <pubDate>Wed, 25 Apr 2007 14:50:40 +0000</pubDate>
        <dc:creator>Lauro Ramos Venancio &lt;lauro.venancio@gmail.com&gt;</dc:creator>
    </item>
</channel>
</rss>
