[polly] r249607 - Allow invariant loads in the SCoP description

[Tobias Grosser via llvm-commits]

On 10/07/2015 10:17 PM, Johannes Doerfert via llvm-commits wrote:
> Author: jdoerfert
> Date: Wed Oct  7 15:17:36 2015
> New Revision: 249607
>
> URL: http://llvm.org/viewvc/llvm-project?rev=249607&view=rev
> Log:
> 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 "required invariant loads" 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't
>    it will be a non-affine expression as before. At the moment we
>    optimistically assume all "hoistable" (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.

Thank you for this patch!

It caused one LNT compile time failure, though:

http://lab.llvm.org:8011/builders/perf-x86_64-penryn-O3-polly-fast/builds/12702

Best,
Tobias