[PATCH] D13338: [Polly] Consolidate invariant loads

[Johannes Doerfert via llvm-commits]

jdoerfert added a comment.

In http://reviews.llvm.org/D13338#257504, @Meinersbur wrote:

> Could you please describe what the code is doing not only in the commit message, but also as source code comment?


I think the source is well documented. If you disagree please inline a comment so I know what part you refer too.

> Why is ScopDetection involved at all?


Because in ScopInfo we cannot build the equivalence classes until the SCoP is completed and to build the SCoP in resonable time we need equivalence classes.
For example in the SCEVAffinator (that is used throughout the SCoP creation) we need to normalize required invariant load parameters otherwise we would introduce different parameters for each invariant load.
To normalize these parameters we already need equivalence classes but in the expression that is translated at that point there might only be a reference to one of the invariant loads (most certainly not to all that are equivalent).
Thus, to determine the representing element for an equivalence class we need to know all elements of it before we use the SCEVAffinator for the first time.
The only way to build the equivalence classses before we use the SCEVAffinator is to do it in the ScopDetection where we actually see all required invariant loads.

> Shouldn't it be ScopInfo alone which decides what that Scop's parameters are?


ScopInfo actually never "really" decides what the parameters are, it only normalizes them to a certain degree (and now even more). The parameters are collected and given to the SCoP by the SCEVAffinator and the SCEVValidator.


http://reviews.llvm.org/D13338