Collaboration diagram for control_flow_regions:

[legend]

Public Member Functions
	control_flow_regions (gimple_seq seq)

bool	is_unconditional_oacc_for_loop (size_t idx)

Private Member Functions
size_t	find_rep (size_t stmt_idx)

void	union_reps (size_t a, size_t b)

void	compute_regions (gimple_seq seq)

Private Attributes
vec< size_t >	representatives

vec< bool >	omp_for_loops

Detailed Description

Auxiliary analysis of the body of a kernels region, to determine for each
OpenACC loop whether it is control-dependent (i.e., not necessarily
executed every time the kernels region is entered) or not.
We say that a loop is control-dependent if there is some cond, switch, or
goto statement that jumps over it, forwards or backwards.  For example,
if the loop is controlled by an if statement, then a jump to the true
block, the false block, or from one of those blocks to the control flow
join point will necessarily jump over the loop.
This analysis implements an ad-hoc union-find data structure classifying
statements into "control-flow regions" as follows: Most statements are in
the same region as their predecessor, except that each OpenACC loop is in
a region of its own, and each OpenACC loop's successor starts a new
region.  We then unite the regions of any statements linked by jumps,
placing any cond, switch, or goto statement in the same region as its
target label(s).
In the end, control dependence of OpenACC loops can be determined by
comparing their immediate predecessor and successor statements' regions.
A jump crosses the loop if and only if the predecessor and successor are
in the same region.  (If there is no predecessor or successor, the loop
is executed unconditionally.)
The methods in this class identify statements by their index in the
kernels region's body.