<?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 vect.omp.force.ll</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>cee313d2 - Revert &quot;Temporarily Revert &quot;Add basic loop fusion pass.&quot;&quot;</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/vect.omp.force.ll#cee313d2</link>
        <description>Revert &quot;Temporarily Revert &quot;Add basic loop fusion pass.&quot;&quot;The reversion apparently deleted the test/Transforms directory.Will be re-reverting again.llvm-svn: 358552

            List of files:
            /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/vect.omp.force.ll</description>
        <pubDate>Wed, 17 Apr 2019 04:52:47 +0000</pubDate>
        <dc:creator>Eric Christopher &lt;echristo@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>978ba615 - Introduce llvm.loop.parallel_accesses and llvm.access.group metadata.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/vect.omp.force.ll#978ba615</link>
        <description>Introduce llvm.loop.parallel_accesses and llvm.access.group metadata.The current llvm.mem.parallel_loop_access metadata has a problem in thatit uses LoopIDs. LoopID unfortunately is not loop identifier. It isneither unique (there&apos;s even a regression test assigning the some LoopIDto multiple loops; can otherwise happen if passes such as LoopVersioningmake copies of entire loops) nor persistent (every time a property isremoved/added from a LoopID&apos;s MDNode, it will also receive a new LoopID;this happens e.g. when calling Loop::setLoopAlreadyUnrolled()).Since most loop transformation passes change the loop attributes (evenif it just to mark that a loop should not be processed again asllvm.loop.isvectorized does, for the versioned and unversioned loop),the parallel access information is lost for any subsequent pass.This patch unlinks LoopIDs and parallel accesses.llvm.mem.parallel_loop_access metadata on instruction is replaced byllvm.access.group metadata. llvm.access.group points to a distinctMDNode with no operands (avoiding the problem to ever need to add/removeoperands), called &quot;access group&quot;. Alternatively, it can point to a listof access groups. The LoopID then has an attributellvm.loop.parallel_accesses with all the access groups that are parallel(no dependencies carries by this loop).This intentionally avoid any kind of &quot;ID&quot;. Loops that are clones/havetheir attributes modifies retain the llvm.loop.parallel_accessesattribute. Access instructions that a cloned point to the same accessgroup. It is not necessary for each access to have it&apos;s own &quot;ID&quot; MDNode,but those memory access instructions with the same behavior can begrouped together.The behavior of llvm.mem.parallel_loop_access is not changed by thispatch, but should be considered deprecated.Differential Revision: https://reviews.llvm.org/D52116llvm-svn: 349725

            List of files:
            /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/vect.omp.force.ll</description>
        <pubDate>Thu, 20 Dec 2018 04:58:07 +0000</pubDate>
        <dc:creator>Michael Kruse &lt;llvm@meinersbur.de&gt;</dc:creator>
    </item>
<item>
        <title>c3d60efb - TTI: Honour cost model for estimating cost of vector-intrinsic and calls.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/vect.omp.force.ll#c3d60efb</link>
        <description>TTI: Honour cost model for estimating cost of vector-intrinsic and calls.Review: http://reviews.llvm.org/D8096llvm-svn: 232528

            List of files:
            /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/vect.omp.force.ll</description>
        <pubDate>Tue, 17 Mar 2015 19:37:28 +0000</pubDate>
        <dc:creator>Michael Zolotukhin &lt;mzolotukhin@apple.com&gt;</dc:creator>
    </item>
<item>
        <title>a79ac14f - [opaque pointer type] Add textual IR support for explicit type parameter to load instruction</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/vect.omp.force.ll#a79ac14f</link>
        <description>[opaque pointer type] Add textual IR support for explicit type parameter to load instructionEssentially the same as the GEP change in r230786.A similar migration script can be used to update test cases, though a few moretest case improvements/changes were required this time around: (r229269-r229278)import fileinputimport sysimport repat = re.compile(r&quot;((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)&quot;)for line in sys.stdin:  sys.stdout.write(re.sub(pat, r&quot;\1, \2\3*\4&quot;, line))Reviewers: rafael, dexonsmith, grosserDifferential Revision: http://reviews.llvm.org/D7649llvm-svn: 230794

            List of files:
            /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/vect.omp.force.ll</description>
        <pubDate>Fri, 27 Feb 2015 21:17:42 +0000</pubDate>
        <dc:creator>David Blaikie &lt;dblaikie@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>79e6c749 - [opaque pointer type] Add textual IR support for explicit type parameter to getelementptr instruction</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/vect.omp.force.ll#79e6c749</link>
        <description>[opaque pointer type] Add textual IR support for explicit type parameter to getelementptr instructionOne of several parallel first steps to remove the target type of pointers,replacing them with a single opaque pointer type.This adds an explicit type parameter to the gep instruction so that when thefirst parameter becomes an opaque pointer type, the type to gep through isstill available to the instructions.* This doesn&apos;t modify gep operators, only instructions (operators will be  handled separately)* Textual IR changes only. Bitcode (including upgrade) and changing the  in-memory representation will be in separate changes.* geps of vectors are transformed as:    getelementptr &lt;4 x float*&gt; %x, ...  -&gt;getelementptr float, &lt;4 x float*&gt; %x, ...  Then, once the opaque pointer type is introduced, this will ultimately look  like:    getelementptr float, &lt;4 x ptr&gt; %x  with the unambiguous interpretation that it is a vector of pointers to float.* address spaces remain on the pointer, not the type:    getelementptr float addrspace(1)* %x  -&gt;getelementptr float, float addrspace(1)* %x  Then, eventually:    getelementptr float, ptr addrspace(1) %xImportantly, the massive amount of test case churn has been automated bysame crappy python code. I had to manually update a few test cases thatwouldn&apos;t fit the script&apos;s model (r228970,r229196,r229197,r229198). Thepython script just massages stdin and writes the result to stdout, Ithen wrapped that in a shell script to handle replacing files, thenusing the usual find+xargs to migrate all the files.update.py:import fileinputimport sysimport reibrep = re.compile(r&quot;(^.*?[^%\w]getelementptr inbounds )(((?:&lt;\d* x )?)(.*?)(| addrspace\(\d\)) *\*(|&gt;)(?:$| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$))&quot;)normrep = re.compile(       r&quot;(^.*?[^%\w]getelementptr )(((?:&lt;\d* x )?)(.*?)(| addrspace\(\d\)) *\*(|&gt;)(?:$| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$))&quot;)def conv(match, line):  if not match:    return line  line = match.groups()[0]  if len(match.groups()[5]) == 0:    line += match.groups()[2]  line += match.groups()[3]  line += &quot;, &quot;  line += match.groups()[1]  line += &quot;\n&quot;  return linefor line in sys.stdin:  if line.find(&quot;getelementptr &quot;) == line.find(&quot;getelementptr inbounds&quot;):    if line.find(&quot;getelementptr inbounds&quot;) != line.find(&quot;getelementptr inbounds (&quot;):      line = conv(re.match(ibrep, line), line)  elif line.find(&quot;getelementptr &quot;) != line.find(&quot;getelementptr (&quot;):    line = conv(re.match(normrep, line), line)  sys.stdout.write(line)apply.sh:for name in &quot;$@&quot;do  python3 `dirname &quot;$0&quot;`/update.py &lt; &quot;$name&quot; &gt; &quot;$name.tmp&quot; &amp;&amp; mv &quot;$name.tmp&quot; &quot;$name&quot;  rm -f &quot;$name.tmp&quot;doneThe actual commands:From llvm/src:find test/ -name *.ll | xargs ./apply.shFrom llvm/src/tools/clang:find test/ -name *.mm -o -name *.m -o -name *.cpp -o -name *.c | xargs -I &apos;{}&apos; ../../apply.sh &quot;{}&quot;From llvm/src/tools/polly:find test/ -name *.ll | xargs ./apply.shAfter that, check-all (with llvm, clang, clang-tools-extra, lld,compiler-rt, and polly all checked out).The extra &apos;rm&apos; in the apply.sh script is due to a few files in clang&apos;s testsuite using interesting unicode stuff that my python script was throwingexceptions on. None of those files needed to be migrated, so it seemedsufficient to ignore those cases.Reviewers: rafael, dexonsmith, grosserDifferential Revision: http://reviews.llvm.org/D7636llvm-svn: 230786

            List of files:
            /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/vect.omp.force.ll</description>
        <pubDate>Fri, 27 Feb 2015 19:29:02 +0000</pubDate>
        <dc:creator>David Blaikie &lt;dblaikie@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>be7ea19b - IR: Make metadata typeless in assembly</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/vect.omp.force.ll#be7ea19b</link>
        <description>IR: Make metadata typeless in assemblyNow that `Metadata` is typeless, reflect that in the assembly.  Theseare the matching assembly changes for the metadata/value split inr223802.  - Only use the `metadata` type when referencing metadata from a call    intrinsic -- i.e., only when it&apos;s used as a `Value`.  - Stop pretending that `ValueAsMetadata` is wrapped in an `MDNode`    when referencing it from call intrinsics.So, assembly like this:    define @foo(i32 %v) {      call void @llvm.foo(metadata !{i32 %v}, metadata !0)      call void @llvm.foo(metadata !{i32 7}, metadata !0)      call void @llvm.foo(metadata !1, metadata !0)      call void @llvm.foo(metadata !3, metadata !0)      call void @llvm.foo(metadata !{metadata !3}, metadata !0)      ret void, !bar !2    }    !0 = metadata !{metadata !2}    !1 = metadata !{i32* @global}    !2 = metadata !{metadata !3}    !3 = metadata !{}turns into this:    define @foo(i32 %v) {      call void @llvm.foo(metadata i32 %v, metadata !0)      call void @llvm.foo(metadata i32 7, metadata !0)      call void @llvm.foo(metadata i32* @global, metadata !0)      call void @llvm.foo(metadata !3, metadata !0)      call void @llvm.foo(metadata !{!3}, metadata !0)      ret void, !bar !2    }    !0 = !{!2}    !1 = !{i32* @global}    !2 = !{!3}    !3 = !{}I wrote an upgrade script that handled almost all of the tests in llvmand many of the tests in cfe (even handling many `CHECK` lines).  I&apos;veattached it (or will attach it in a moment if you&apos;re speedy) to PR21532to help everyone update their out-of-tree testcases.This is part of PR21532.llvm-svn: 224257

            List of files:
            /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/vect.omp.force.ll</description>
        <pubDate>Mon, 15 Dec 2014 19:07:53 +0000</pubDate>
        <dc:creator>Duncan P. N. Exon Smith &lt;dexonsmith@apple.com&gt;</dc:creator>
    </item>
<item>
        <title>5d5e18da - Rename loop unrolling and loop vectorizer metadata to have a common prefix.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/vect.omp.force.ll#5d5e18da</link>
        <description>Rename loop unrolling and loop vectorizer metadata to have a common prefix.[LLVM part]These patches rename the loop unrolling and loop vectorizer metadatasuch that they have a common &apos;llvm.loop.&apos; prefix.  Metadata namechanges:llvm.vectorizer.* =&gt; llvm.loop.vectorizer.*llvm.loopunroll.* =&gt; llvm.loop.unroll.*This was a suggestion from an earlier review(http://reviews.llvm.org/D4090) which added the loop unrollingmetadata. Patch by Mark Heffernan.llvm-svn: 211710

            List of files:
            /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/vect.omp.force.ll</description>
        <pubDate>Wed, 25 Jun 2014 15:41:00 +0000</pubDate>
        <dc:creator>Eli Bendersky &lt;eliben@google.com&gt;</dc:creator>
    </item>
<item>
        <title>d373fec1 - [OPENMP][LV][D3423] Respect Hints.Force meta-data for loops in LoopVectorizer</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/vect.omp.force.ll#d373fec1</link>
        <description>[OPENMP][LV][D3423] Respect Hints.Force meta-data for loops in LoopVectorizerllvm-svn: 207512

            List of files:
            /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/vect.omp.force.ll</description>
        <pubDate>Tue, 29 Apr 2014 08:55:11 +0000</pubDate>
        <dc:creator>Zinovy Nis &lt;zinovy.nis@gmail.com&gt;</dc:creator>
    </item>
</channel>
</rss>
