Movatterモバイル変換

• llvm
• CanonicalLoopInfo

Class to represented the control flow structure of an OpenMP canonical loop.

The control-flow structure is standardized for easy consumption by directives associated with loops. For instance, the worksharing-loop construct may change this control flow such that each loop iteration is executed on only one thread. The constraints of a canonical loop in brief are:

• The number of loop iterations must have been computed before entering the loop.
• Has an (unsigned) logical induction variable that starts at zero and increments by one.
• The loop's CFG itself has no side-effects. The OpenMP specification itself allows side-effects, but the order in which they happen, including how often or whether at all, is unspecified. We expect that the frontend will emit those side-effect instructions somewhere (e.g. before the loop) such that theCanonicalLoopInfo itself can be side-effect free.

Keep in mind thatCanonicalLoopInfo is meant to only describe a repeated execution of a loop body that satifies these constraints. It does NOT represent arbitrary SESE regions that happen to contain a loop. Do not useCanonicalLoopInfo for such purposes.

The control flow can be described as follows:

Preheader   |

/-> Header | | | Cond—\ | | | | Body | | | | | | <...> | | | | | --Latch | | Exit | After

The loop is thought to start at PreheaderIP (at the Preheader's terminator, including) and end at AfterIP (at the After's first instruction, excluding). That is, instructions in the Preheader and After blocks (except the Preheader's terminator) are out ofCanonicalLoopInfo's control and may have side-effects. Typically, the Preheader is used to compute the loop's trip count. The instructions from BodyIP (at the Body block's first instruction, excluding) until the Latch are also considered outsideCanonicalLoopInfo's control and thus can have side-effects. The body block is the single entry point into the loop body, which may contain arbitrary control flow as long as all control paths eventually branch to the Latch block.

TODO: Consider adding another standardizedBasicBlock between Body CFG and Latch to guarantee that there is only a single edge to the latch. It would make loop transformations easier to not needing to consider multiple predecessors of the latch (See redirectAllPredecessorsTo) and would give us an equivalant to PreheaderIP, AfterIP and BodyIP for inserting code that executes after each body iteration.

There must be no loop-carried dependencies through llvm::Values. This is equivalant to that the Latch has noPHINode and the Header's onlyPHINode is for the induction variable.

All code in Header, Cond, Latch and Exit (plus the terminator of the Preheader) areCanonicalLoopInfo's responsibility and their build-up checked byassertOK(). They are expected to not be modified unless explicitly modifying theCanonicalLoopInfo through a methods that applies a OpenMP loop-associated construct such as applyWorkshareLoop, tileLoops, unrollLoop, etc. These methods usually invalidate theCanonicalLoopInfo and re-use its basic blocks. After invalidation, theCanonicalLoopInfo must not be used anymore as its underlying control flow may not exist anymore. Loop-transformation methods such as tileLoops, collapseLoops and unrollLoop may also return a newCanonicalLoopInfo that can be passed to other loop-associated construct implementing methods. These loop-transforming methods may either create a newCanonicalLoopInfo usually using createLoopSkeleton and invalidate the inputCanonicalLoopInfo, or reuse and modify one of the inputCanonicalLoopInfo and return it as representing the modified loop. What is done is an implementation detail of transformation-implementing method and callers should always assume that theCanonicalLoopInfo passed to it is invalidated and a new object is returned. ReturnedCanonicalLoopInfo have the same structure and guarantees as the one created by createCanonicalLoop, such that transforming methods do not have to special case where theCanonicalLoopInfo originated from.

Generally, methods consumingCanonicalLoopInfo do not need anOpenMPIRBuilder::InsertPointTy as argument, but use the locations of theCanonicalLoopInfo to insert new or modify existing instructions. Unless documented otherwise, methods consumingCanonicalLoopInfo do not invalidate any InsertPoint that is outsideCanonicalLoopInfo's control. Specifically, any InsertPoint in the Preheader, After or Block can still be used after calling such a method.

TODO: Provide mechanisms for exception handling and cancellation points.

Defined outsideOpenMPIRBuilder because nested classes cannot be forward-declared, e.g. to avoid having to include the entireOMPIRBuilder.h.

Definition at line3512 of fileOMPIRBuilder.h.