<?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 scalable-lifetime.ll</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>3fd96e1b - [LoopVectorize] Improve vectorisation of some intrinsics by treating them as uniform</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/scalable-lifetime.ll#3fd96e1b</link>
        <description>[LoopVectorize] Improve vectorisation of some intrinsics by treating them as uniformThis patch adds more instructions to the Uniforms list, for example certainintrinsics that are uniform by definition or whose operands are loop invariant.This list includes:  1. The intrinsics &apos;experimental.noalias.scope.decl&apos; and &apos;sideeffect&apos;, which  are always uniform by definition.  2. If intrinsics &apos;lifetime.start&apos;, &apos;lifetime.end&apos; and &apos;assume&apos; have  loop invariant input operands then these are also uniform too.Also, in VPRecipeBuilder::handleReplication we check if an instruction isuniform based purely on whether or not the instruction lives in the Uniformslist. However, there are certain cases where calls to some intrinsics canbe effectively treated as uniform too. Therefore, we now also treat thefollowing cases as uniform for scalable vectors:  1. If the &apos;assume&apos; intrinsic&apos;s operand is not loop invariant, then we  are free to treat this as uniform anyway since it&apos;s only a performance  hint. We will get the benefit for the first lane.  2. When the input pointers for &apos;lifetime.start&apos; and &apos;lifetime.end&apos; are loop  variant then for scalable vectors we assume these still ultimately come  from the broadcast of an alloca. We do not support scalable vectorisation  of loops containing alloca instructions, hence the alloca itself would  be invariant. If the pointer does not come from an alloca then the  intrinsic itself has no effect.I have updated the assume test for fixed width, since we now treat itas uniform:  Transforms/LoopVectorize/assume.llI&apos;ve also added new scalable vectorisation tests for other intriniscs:  Transforms/LoopVectorize/scalable-assume.ll  Transforms/LoopVectorize/scalable-lifetime.ll  Transforms/LoopVectorize/scalable-noalias-scope-decl.llDifferential Revision: https://reviews.llvm.org/D107284

            List of files:
            /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/scalable-lifetime.ll</description>
        <pubDate>Fri, 30 Jul 2021 07:41:31 +0000</pubDate>
        <dc:creator>David Sherwood &lt;david.sherwood@arm.com&gt;</dc:creator>
    </item>
<item>
        <title>95800da9 - [LoopVectorize] Add support for replication of more intrinsics with scalable vectors</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/scalable-lifetime.ll#95800da9</link>
        <description>[LoopVectorize] Add support for replication of more intrinsics with scalable vectorsThis patch adds more instructions to the Uniforms list, for example certainintrinsics that are uniform by definition or whose operands are loop invariant.This list includes:  1. The intrinsics &apos;experimental.noalias.scope.decl&apos; and &apos;sideeffect&apos;, which  are always uniform by definition.  2. If intrinsics &apos;lifetime.start&apos;, &apos;lifetime.end&apos; and &apos;assume&apos; have  loop invariant input operands then these are also uniform too.Also, in VPRecipeBuilder::handleReplication we check if an instruction isuniform based purely on whether or not the instruction lives in the Uniformslist. However, there are certain cases where calls to some intrinsics canbe effectively treated as uniform too. Therefore, we now also treat thefollowing cases as uniform for scalable vectors:  1. If the &apos;assume&apos; intrinsic&apos;s operand is not loop invariant, then we  are free to treat this as uniform anyway since it&apos;s only a performance  hint. We will get the benefit for the first lane.  2. When the input pointers for &apos;lifetime.start&apos; and &apos;lifetime.end&apos; are loop  variant then for scalable vectors we assume these still ultimately come  from the broadcast of an alloca. We do not support scalable vectorisation  of loops containing alloca instructions, hence the alloca itself would  be invariant. If the pointer does not come from an alloca then the  intrinsic itself has no effect.I have updated the assume test for fixed width, since we now treat itas uniform:  Transforms/LoopVectorize/assume.llI&apos;ve also added new scalable vectorisation tests for other intriniscs:  Transforms/LoopVectorize/scalable-assume.ll  Transforms/LoopVectorize/scalable-lifetime.ll  Transforms/LoopVectorize/scalable-noalias-scope-decl.llDifferential Revision: https://reviews.llvm.org/D107284

            List of files:
            /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/scalable-lifetime.ll</description>
        <pubDate>Fri, 30 Jul 2021 07:41:31 +0000</pubDate>
        <dc:creator>David Sherwood &lt;david.sherwood@arm.com&gt;</dc:creator>
    </item>
</channel>
</rss>
