<?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 invariant_load_base_pointer_conditional.ll</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>5c028081 - [polly] Introduce -polly-print-* passes to replace -analyze.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/polly/test/ScopInfo/invariant_load_base_pointer_conditional.ll#5c028081</link>
        <description>[polly] Introduce -polly-print-* passes to replace -analyze.The `opt -analyze` option only works with the legacy pass manager and might be removed in the future, as explained in llvm.org/PR53733. This patch introduced -polly-print-* passes that print what the pass would print with the `-analyze` option and replaces all uses of `-analyze` in the regression tests.There are two exceptions: `CodeGen\single_loop_param_less_equal.ll` and `CodeGen\loop_with_condition_nested.ll` use `-analyze on the `-loops` pass which is not part of Polly.Reviewed By: aeubanksDifferential Revision: https://reviews.llvm.org/D120782

            List of files:
            /llvm-project-15.0.7/polly/test/ScopInfo/invariant_load_base_pointer_conditional.ll</description>
        <pubDate>Mon, 14 Mar 2022 13:39:25 +0000</pubDate>
        <dc:creator>Michael Kruse &lt;llvm-project@meinersbur.de&gt;</dc:creator>
    </item>
<item>
        <title>6e6264c1 - [tests] Force invariant load hoisting for test cases that need it</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/polly/test/ScopInfo/invariant_load_base_pointer_conditional.ll#6e6264c1</link>
        <description>[tests] Force invariant load hoisting for test cases that need itThis will make it easier to switch the default of Polly&apos;s invariant loadhoisting strategy and also makes it very clear that these test casesindeed require invariant code hoisting to work.llvm-svn: 278667

            List of files:
            /llvm-project-15.0.7/polly/test/ScopInfo/invariant_load_base_pointer_conditional.ll</description>
        <pubDate>Mon, 15 Aug 2016 13:27:49 +0000</pubDate>
        <dc:creator>Tobias Grosser &lt;tobias@grosser.es&gt;</dc:creator>
    </item>
<item>
        <title>09e3697f - Allow invariant loads in the SCoP description</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/polly/test/ScopInfo/invariant_load_base_pointer_conditional.ll#09e3697f</link>
        <description>Allow invariant loads in the SCoP description  This patch allows invariant loads to be used in the SCoP description,  e.g., as loop bounds, conditions or in memory access functions.  First we collect &quot;required invariant loads&quot; during SCoP detection that  would otherwise make an expression we care about non-affine. To this  end a new level of abstraction was introduced before  SCEVValidator::isAffineExpr() namely ScopDetection::isAffine() and  ScopDetection::onlyValidRequiredInvariantLoads(). Here we can decide  if we want a load inside the region to be optimistically assumed  invariant or not. If we do, it will be marked as required and in the  SCoP generation we bail if it is actually not invariant. If we don&apos;t  it will be a non-affine expression as before. At the moment we  optimistically assume all &quot;hoistable&quot; (namely non-loop-carried) loads  to be invariant. This causes us to expand some SCoPs and dismiss them  later but it also allows us to detect a lot we would dismiss directly  if we would ask e.g., AliasAnalysis::canBasicBlockModify(). We also  allow potential aliases between optimistically assumed invariant loads  and other pointers as our runtime alias checks are sound in case the  loads are actually invariant. Together with the invariant checks this  combination allows to handle a lot more than LICM can.  The code generation of the invariant loads had to be extended as we  can now have dependences between parameters and invariant (hoisted)  loads as well as the other way around, e.g.,    test/Isl/CodeGen/invariant_load_parameters_cyclic_dependence.ll  First, it is important to note that we cannot have real cycles but  only dependences from a hoisted load to a parameter and from another  parameter to that hoisted load (and so on). To handle such cases we  materialize llvm::Values for parameters that are referred by a hoisted  load on demand and then materialize the remaining parameters. Second,  there are new kinds of dependences between hoisted loads caused by the  constraints on their execution. If a hoisted load is conditionally  executed it might depend on the value of another hoisted load. To deal  with such situations we sort them already in the ScopInfo such that  they can be generated in the order they are listed in the  Scop::InvariantAccesses list (see compareInvariantAccesses). The  dependences between hoisted loads caused by indirect accesses are  handled the same way as before.llvm-svn: 249607

            List of files:
            /llvm-project-15.0.7/polly/test/ScopInfo/invariant_load_base_pointer_conditional.ll</description>
        <pubDate>Wed, 07 Oct 2015 20:17:36 +0000</pubDate>
        <dc:creator>Johannes Doerfert &lt;doerfert@cs.uni-saarland.de&gt;</dc:creator>
    </item>
</channel>
</rss>
