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

[Johannes Doerfert via llvm-commits]

Sorry, it was caused by this patch and a piece of code I removed last
minute cause I though it would not be needed at the moment. I was wrong.

I fixed it by committing the missing projection from parameters from the
invariant load domains that referee to the invariant load itself.

Should be fixed in r249680.

On 10/08, Tobias Grosser wrote:
> 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

-- 

Johannes Doerfert
Researcher / PhD Student

Compiler Design Lab (Prof. Hack)
Saarland University, Computer Science
Building E1.3, Room 4.31

Tel. +49 (0)681 302-57521 : doerfert at cs.uni-saarland.de
Fax. +49 (0)681 302-3065  : http://www.cdl.uni-saarland.de/people/doerfert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151008/c5b10cca/attachment.sig>