Page MenuHomePhabricator

[Polly] Allow invariant loads in the SCoP description

Authored by jdoerfert on Sep 26 2015, 2:18 PM.


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.,
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.

Diff Detail

Event Timeline

jdoerfert updated this revision to Diff 35812.Sep 26 2015, 2:18 PM
jdoerfert retitled this revision from to [Polly] Allow definitively invariant loads in the SCoP description.
jdoerfert added reviewers: grosser, Meinersbur.
jdoerfert updated this object.
jdoerfert added a subscriber: Restricted Project.
grosser edited edge metadata.Sep 28 2015, 1:13 AM








jdoerfert updated this revision to Diff 36217.Oct 1 2015, 4:05 AM
jdoerfert edited edge metadata.

Rebase to current HEAD and fixed all known errors for lnt

jdoerfert retitled this revision from [Polly] Allow definitively invariant loads in the SCoP description to [Polly] Allow invariant loads in the SCoP description.Oct 1 2015, 4:05 AM
jdoerfert updated this object.
grosser accepted this revision.Oct 6 2015, 1:25 PM
grosser edited edge metadata.



remember (unrelated, but could be fixed as well)


This is very brief. It might be a good place to put an overview (and some examples of your approach).


We should use an AssertingVH<LoadInst> to ensure we do not have dangling pointers.


, we can


You can use 'auto' here.

Also, "Load' instead of "LInst" seams easier to read.


RILMIt? Just I seems fine for an iterator variable with minimal scop. it is easier to remember and as understandable as RILMIt.


A little example would make this a bit more understandable.


errs() -> dbgs()




Maybe explain why the order matters.

This revision is now accepted and ready to land.Oct 6 2015, 1:25 PM
jdoerfert added inline comments.Oct 7 2015, 8:09 AM

Will be removed in a few days by a simplification commit anyway.

jdoerfert closed this revision.Oct 7 2015, 1:35 PM

commited in r249607