- Generated by
1.8.1.1
|
GCC Middle and Back End API Reference
|
| tree bump_vector_ptr | ( | tree | dataref_ptr, |
| gimple | ptr_incr, | ||
| gimple_stmt_iterator * | gsi, | ||
| gimple | stmt, | ||
| tree | bump | ||
| ) |
@verbatim
Function bump_vector_ptr
Increment a pointer (to a vector type) by vector-size. If requested, i.e. if PTR-INCR is given, then also connect the new increment stmt to the existing def-use update-chain of the pointer, by modifying the PTR_INCR as illustrated below:
The pointer def-use update-chain before this function: DATAREF_PTR = phi (p_0, p_2) .... PTR_INCR: p_2 = DATAREF_PTR + step
The pointer def-use update-chain after this function: DATAREF_PTR = phi (p_0, p_2) .... NEW_DATAREF_PTR = DATAREF_PTR + BUMP .... PTR_INCR: p_2 = NEW_DATAREF_PTR + step
Input: DATAREF_PTR - ssa_name of a pointer (to vector type) that is being updated in the loop. PTR_INCR - optional. The stmt that updates the pointer in each iteration of the loop. The increment amount across iterations is expected to be vector_size. BSI - location where the new update stmt is to be placed. STMT - the original scalar memory-access stmt that is being vectorized. BUMP - optional. The offset by which to bump the pointer. If not given, the offset is assumed to be vector_size.
Output: Return NEW_DATAREF_PTR as illustrated above.
Copy the points-to information if it exists.
Update the vector-pointer's cross-iteration increment.
|
static |
A helper function used in the comparator function to sort data
references. T1 and T2 are two data references to be compared.
The function returns -1, 0, or 1. For const values, we can just use hash values for comparisons.
For var-decl, we could compare their UIDs.
For expressions with operands, compare their operands recursively.
|
static |
Compare two data-references DRA and DRB to group them into chunks suitable for grouping.
Stabilize sort.
Ordering of DRs according to base.
And according to DR_OFFSET.
Put reads before writes.
Then sort after access size.
And after step.
Then sort after DR_INIT. In case of identical DRs sort after stmt UID.
References DR_REF, dump_generic_expr(), dump_printf(), dump_printf_loc(), and vect_location.
|
static |
Given an memory reference EXP return whether its alignment is less than its size.
Referenced by vect_permute_load_chain().
|
static |
Analyze the access pattern of the data-reference DR. In case of non-consecutive accesses call vect_analyze_group_access() to analyze groups of accesses.
Allow invariant loads in not nested loops.
Interleaved accesses are not yet supported within outer-loop
vectorization for references in the inner-loop. For the rest of the analysis we use the outer-loop step.
Consecutive?
Mark that it is not interleaving.
Assume this is a DR handled by non-constant strided load case.
Not consecutive access - check if it's a part of interleaving group.
| bool vect_analyze_data_ref_accesses | ( | ) |
Function vect_analyze_data_ref_accesses.
Analyze the access pattern of all the data references in the loop.
FORNOW: the only access pattern that is considered vectorizable is a
simple step 1 (consecutive) access.
FORNOW: handle only arrays and pointer accesses. Sort the array of datarefs to make building the interleaving chains
linear. Build the interleaving chains.
??? Imperfect sorting (non-compatible types, non-modulo
accesses, same accesses) can lead to a group to be artificially
split here as we don't just skip over those. If it really
matters we can push those to a worklist and re-iterate
over them. The we can just skip ahead to the next DR here. Check that the data-refs have same first location (except init)
and they are both either store or load (not load and store). Check that the data-refs have the same constant size and step.
Do not place the same access in the interleaving chain twice.
Check the types are compatible.
??? We don't distinguish this during sorting. Sorting has ensured that DR_INIT (dra) <= DR_INIT (drb).
If init_b == init_a + the size of the type * k, we have an
interleaving, and DRA is accessed before DRB. The step (if not zero) is greater than the difference between
data-refs' inits. This splits groups into suitable sizes. Link the found element into the group list.
Mark the statement as not vectorizable.
References DDR_A, DDR_B, DR_REF, dump_enabled_p(), dump_generic_expr(), dump_printf(), dump_printf_loc(), and vect_location.
|
static |
Function vect_analyze_data_ref_dependence. Return TRUE if there (might) exist a dependence between a memory-reference DRA and a memory-reference DRB. When versioning for alias may check a dependence at run-time, return FALSE. Adjust *MAX_VF according to the data dependence.
In loop analysis all data references should be vectorizable.
Independent data accesses.
Unknown data dependence.
If user asserted safelen consecutive iterations can be
executed concurrently, assume independence. Add to list of ddrs that need to be tested at run-time.
Known data dependence.
If user asserted safelen consecutive iterations can be
executed concurrently, assume independence. Add to list of ddrs that need to be tested at run-time.
When we perform grouped accesses and perform implicit CSE
by detecting equal accesses and doing disambiguation with
runtime alias tests like for
.. = a[i];
.. = a[i+1];
a[i] = ..;
a[i+1] = ..;
*p = ..;
.. = a[i];
.. = a[i+1];
where we will end up loading { a[i], a[i+1] } once, make
sure that inserting group loads before the first load and
stores after the last store will do the right thing. If DDR_REVERSED_P the order of the data-refs in DDR was
reversed (to make distance vector positive), and the actual
distance is negative. The dependence distance requires reduction of the maximal
vectorization factor. Dependence distance does not create dependence, as far as
vectorization is concerned, in this case.
| bool vect_analyze_data_ref_dependences | ( | ) |
Function vect_analyze_data_ref_dependences. Examine all the data references in the loop, and make sure there do not exist any data dependences between them. Set *MAX_VF according to the maximum vectorization factor the data dependences allow.
References chrec_known, DDR_A, DDR_ARE_DEPENDENT, DDR_B, DR_IS_READ, DR_STMT, and vinfo_for_stmt().
| bool vect_analyze_data_refs | ( | loop_vec_info | loop_vinfo, |
| bb_vec_info | bb_vinfo, | ||
| int * | min_vf | ||
| ) |
@verbatim
Function vect_analyze_data_refs.
Find all the data references in the loop or basic block.
The general structure of the analysis of data refs in the vectorizer is as follows: 1- vect_analyze_data_refs(loop/bb): call compute_data_dependences_for_loop/bb to find and analyze all data-refs in the loop/bb and their dependences. 2- vect_analyze_dependences(): apply dependence testing using ddrs. 3- vect_analyze_drs_alignment(): check that ref_stmt.alignment is ok. 4- vect_analyze_drs_access(): check that ref_stmt.step is ok.
Mark the rest of the basic-block as unvectorizable.
Go through the data-refs, check that the analysis succeeded. Update
pointer from stmt_vec_info struct to DR and vectype. Discard clobbers from the dataref vector. We will remove
clobber stmts during vectorization. Check that analysis of the data-ref succeeded.
If target supports vector gather loads, or if this might be
a SIMD lane access, see if they can't be used. For now.
Update DR field in stmt_vec_info struct.
If the dataref is in an inner-loop of the loop that is considered for
for vectorization, we also want to analyze the access relative to
the outer-loop (DR contains information only relative to the
inner-most enclosing loop). We do that by building a reference to the
first location accessed by the inner-loop, and analyze it relative to
the outer-loop. Build a reference to the first location accessed by the
inner-loop: *(BASE+INIT). (The first location is actually
BASE+INIT+OFFSET, but we add OFFSET separately later). FIXME: Use canonicalize_base_object_address (base_iv.base);
Set vectype for STMT.
Adjust the minimal vectorization factor according to the
vector type. If we stopped analysis at the first dataref we could not analyze
when trying to vectorize a basic-block mark the rest of the datarefs
as not vectorizable and truncate the vector of datarefs. That
avoids spending useless time in analyzing their dependence.
| bool vect_analyze_data_refs_alignment | ( | loop_vec_info | loop_vinfo, |
| bb_vec_info | bb_vinfo | ||
| ) |
Function vect_analyze_data_refs_alignment Analyze the alignment of the data-references in the loop. Return FALSE if a data reference is found that cannot be vectorized.
Mark groups of data references with same alignment using
data dependence information.
|
static |
Analyze groups of accesses: check that DR belongs to a group of accesses of legal size, step, etc. Detect gaps, single element interleaving, and other special cases. Set grouped access info. Collect groups of strided stores for further use in SLP analysis.
For interleaving, GROUPSIZE is STEP counted in elements, i.e., the
size of the interleaving group (including gaps). Not consecutive access is possible only if it is a part of interleaving.
Check if it this DR is a part of interleaving, and is a single
element of the group that is accessed in the loop. Gaps are supported only for loads. STEP must be a multiple of the type
size. The size of the group must be a power of 2. Mark the statement as unvectorizable.
First stmt in the interleaving chain. Check the chain.
Skip same data-refs. In case that two or more stmts share
data-ref (supported only for loads), we vectorize only the first
stmt, and the rest get their vectorized loads from the first
one. For load use the same data-ref load.
All group members have the same STEP by construction.
Check that the distance between two accesses is equal to the type
size. Otherwise, we have gaps. FORNOW: SLP of accesses with gaps is not supported.
Store the gap from the previous member of the group. If there is no
gap in the access, GROUP_GAP is always 1. Count the number of data-refs in the chain.
COUNT is the number of accesses found, we multiply it by the size of
the type to get COUNT_IN_BYTES. Check that the size of the interleaving (including gaps) is not
greater than STEP. Check that the size of the interleaving is equal to STEP for stores,
i.e., that there are no gaps. There is a gap after the last load in the group. This gap is a
difference between the groupsize and the number of elements.
When there is no gap, this difference should be 0. Check that STEP is a multiple of type size.
SLP: create an SLP data structure for every interleaving group of
stores for further analysis in vect_analyse_slp. There is a gap in the end of the group.
| bool vect_can_force_dr_alignment_p | ( | ) |
Function vect_force_dr_alignment_p. Returns whether the alignment of a DECL can be forced to be aligned on ALIGNMENT bit boundary.
We cannot change alignment of common or external symbols as another
translation unit may contain a definition with lower alignment.
The rules of common symbol linking mean that the definition
will override the common symbol. The same is true for constant
pool entries which may be shared and are not properly merged
by LTO. Do not override the alignment as specified by the ABI when the used
attribute is set. Do not override explicit alignment set by the user when an explicit
section name is also used. This is a common idiom used by many
software projects.
| tree vect_check_gather | ( | gimple | stmt, |
| loop_vec_info | loop_vinfo, | ||
| tree * | basep, | ||
| tree * | offp, | ||
| int * | scalep | ||
| ) |
Check whether a non-affine read in stmt is suitable for gather load and if so, return a builtin decl for that operation.
The gather builtins need address of the form
loop_invariant + vector * {1, 2, 4, 8}
or
loop_invariant + sign_extend (vector) * { 1, 2, 4, 8 }.
Unfortunately DR_BASE_ADDRESS/DR_OFFSET can be a mixture
of loop invariants/SSA_NAMEs defined in the loop, with casts,
multiplications and additions in it. To get a vector, we need
a single SSA_NAME that will be defined in the loop and will
contain everything that is not loop invariant and that can be
vectorized. The following code attempts to find such a preexistng
SSA_NAME OFF and put the loop invariants into a tree BASE
that can be gimplified before the loop. If base is not loop invariant, either off is 0, then we start with just
the constant offset in the loop invariant BASE and continue with base
as OFF, otherwise give up.
We could handle that case by gimplifying the addition of base + off
into some SSA_NAME and use that as off, but for now punt. Otherwise put base + constant offset into the loop invariant BASE
and continue with OFF. OFF at this point may be either a SSA_NAME or some tree expression
from get_inner_reference. Try to peel off loop invariants from it
into BASE as long as possible. If at the end OFF still isn't a SSA_NAME or isn't
defined in the loop, punt.
References targetm.
|
static |
Function vect_compute_data_ref_alignment
Compute the misalignment of the data reference DR.
Output:
1. If during the misalignment computation it is found that the data reference
cannot be vectorized then false is returned.
2. DR_MISALIGNMENT (DR) is defined.
FOR NOW: No analysis is actually performed. Misalignment is calculated
only for trivial cases. TODO. Initialize misalignment to unknown.
Strided loads perform only component accesses, misalignment information
is irrelevant for them. In case the dataref is in an inner-loop of the loop that is being
vectorized (LOOP), we use the base and misalignment information
relative to the outer-loop (LOOP). This is ok only if the misalignment
stays the same throughout the execution of the inner-loop, which is why
we have to check that the stride of the dataref in the inner-loop evenly
divides by the vector size. Similarly, if we're doing basic-block vectorization, we can only use
base and misalignment information relative to an innermost loop if the
misalignment stays the same throughout the execution of the loop.
As above, this is the case if the stride of the dataref evenly divides
by the vector size. Do not change the alignment of global variables here if
flag_section_anchors is enabled as we already generated
RTL for other functions. Most global variables should
have been aligned during the IPA increase_alignment pass. Force the alignment of the decl.
NOTE: This is the only change to the code we make during
the analysis phase, before deciding to vectorize the loop. If this is a backward running DR then first access in the larger
vectype actually is N-1 elements before the address in the DR.
Adjust misalign accordingly. DR_STEP(dr) is the same as -TYPE_SIZE of the scalar type,
otherwise we wouldn't be here. PLUS because DR_STEP was negative.
Modulo alignment.
Negative or overflowed misalignment value.
References DR_STEP, dump_enabled_p(), dump_printf_loc(), HOST_WIDE_INT, and vect_location.
|
static |
Function vect_compute_data_refs_alignment Compute the misalignment of data references in the loop. Return FALSE if a data reference is found that cannot be vectorized.
Mark unsupported statement as unvectorizable.
| tree vect_create_addr_base_for_vector_ref | ( | gimple | stmt, |
| gimple_seq * | new_stmt_list, | ||
| tree | offset, | ||
| struct loop * | loop | ||
| ) |
Function vect_create_addr_base_for_vector_ref.
Create an expression that computes the address of the first memory location
that will be accessed for a data reference.
Input:
STMT: The statement containing the data reference.
NEW_STMT_LIST: Must be initialized to NULL_TREE or a statement list.
OFFSET: Optional. If supplied, it is be added to the initial address.
LOOP: Specify relative to which loop-nest should the address be computed.
For example, when the dataref is in an inner-loop nested in an
outer-loop that is now being vectorized, LOOP can be either the
outer-loop, or the inner-loop. The first memory location accessed
by the following dataref ('in' points to short):
for (i=0; i<N; i++)
for (j=0; j<M; j++)
s += in[i+j]
is as follows:
if LOOP=i_loop: &in (relative to i_loop)
if LOOP=j_loop: &in+i*2B (relative to j_loop)
Output:
1. Return an SSA_NAME whose value is the address of the memory location of
the first vector of the data reference.
2. If new_stmt_list is not NULL_TREE after return then the caller must insert
these statement(s) which define the returned SSA_NAME.
FORNOW: We are only handling array accesses with step 1. Create base_offset
base + base_offset
Referenced by vect_do_peeling_for_loop_bound().
| tree vect_create_data_ref_ptr | ( | gimple | stmt, |
| tree | aggr_type, | ||
| struct loop * | at_loop, | ||
| tree | offset, | ||
| tree * | initial_address, | ||
| gimple_stmt_iterator * | gsi, | ||
| gimple * | ptr_incr, | ||
| bool | only_init, | ||
| bool * | inv_p | ||
| ) |
Function vect_create_data_ref_ptr.
Create a new pointer-to-AGGR_TYPE variable (ap), that points to the first
location accessed in the loop by STMT, along with the def-use update
chain to appropriately advance the pointer through the loop iterations.
Also set aliasing information for the pointer. This pointer is used by
the callers to this function to create a memory reference expression for
vector load/store access.
Input:
1. STMT: a stmt that references memory. Expected to be of the form
GIMPLE_ASSIGN <name, data-ref> or
GIMPLE_ASSIGN <data-ref, name>.
2. AGGR_TYPE: the type of the reference, which should be either a vector
or an array.
3. AT_LOOP: the loop where the vector memref is to be created.
4. OFFSET (optional): an offset to be added to the initial address accessed
by the data-ref in STMT.
5. BSI: location where the new stmts are to be placed if there is no loop
6. ONLY_INIT: indicate if ap is to be updated in the loop, or remain
pointing to the initial address.
Output:
1. Declare a new ptr to vector_type, and have it point to the base of the
data reference (initial addressed accessed by the data reference).
For example, for vector of type V8HI, the following code is generated:
v8hi *ap;
ap = (v8hi *)initial_address;
if OFFSET is not supplied:
initial_address = &a[init];
if OFFSET is supplied:
initial_address = &a[init + OFFSET];
Return the initial_address in INITIAL_ADDRESS.
2. If ONLY_INIT is true, just return the initial pointer. Otherwise, also
update the pointer in each iteration of the loop.
Return the increment stmt that updates the pointer in PTR_INCR.
3. Set INV_P to true if the access pattern of the data reference in the
vectorized loop is invariant. Set it to false otherwise.
4. Return the pointer. Check the step (evolution) of the load in LOOP, and record
whether it's invariant. Create an expression for the first address accessed by this load
in LOOP. (1) Create the new aggregate-pointer variable.
Vector and array types inherit the alias set of their component
type by default so we need to use a ref-all pointer if the data
reference does not conflict with the created aggregated data
reference because it is not addressable. Likewise for any of the data references in the stmt group.
Note: If the dataref is in an inner-loop nested in LOOP, and we are
vectorizing LOOP (i.e., outer-loop vectorization), we need to create two
def-use update cycles for the pointer: one relative to the outer-loop
(LOOP), which is what steps (3) and (4) below do. The other is relative
to the inner-loop (which is the inner-most loop containing the dataref),
and this is done be step (5) below.
When vectorizing inner-most loops, the vectorized loop (LOOP) is also the
inner-most loop, and so steps (3),(4) work the same, and step (5) is
redundant. Steps (3),(4) create the following:
vp0 = &base_addr;
LOOP: vp1 = phi(vp0,vp2)
...
...
vp2 = vp1 + step
goto LOOP
If there is an inner-loop nested in loop, then step (5) will also be
applied, and an additional update in the inner-loop will be created:
vp0 = &base_addr;
LOOP: vp1 = phi(vp0,vp2)
...
inner: vp3 = phi(vp1,vp4)
vp4 = vp3 + inner_step
if () goto inner
...
vp2 = vp1 + step
if () goto LOOP (2) Calculate the initial address of the aggregate-pointer, and set
the aggregate-pointer to point to it before the loop. Create: (&(base[init_val+offset]) in the loop preheader.
Create: p = (aggr_type *) initial_base
Copy the points-to information if it exists.
(3) Handle the updating of the aggregate-pointer inside the loop.
This is needed when ONLY_INIT is false, and also when AT_LOOP is the
inner-loop nested in LOOP (during outer-loop vectorization). No update in loop is required.
The step of the aggregate pointer is the type size.
One exception to the above is when the scalar step of the load in
LOOP is zero. In this case the step here is also zero. Copy the points-to information if it exists.
(4) Handle the updating of the aggregate-pointer inside the inner-loop
nested in LOOP, if exists. Copy the points-to information if it exists.
Referenced by vect_permute_store_chain().
| tree vect_create_destination_var | ( | ) |
Function vect_create_destination_var. Create a new temporary of type VECTYPE.
Referenced by vect_permute_store_chain().
| bool vect_enhance_data_refs_alignment | ( | ) |
Function vect_enhance_data_refs_alignment
This pass will use loop versioning and loop peeling in order to enhance
the alignment of data references in the loop.
FOR NOW: we assume that whatever versioning/peeling takes place, only the
original loop is to be vectorized. Any other loops that are created by
the transformations performed in this pass - are not supposed to be
vectorized. This restriction will be relaxed.
This pass will require a cost model to guide it whether to apply peeling
or versioning or a combination of the two. For example, the scheme that
intel uses when given a loop with several memory accesses, is as follows:
choose one memory access ('p') which alignment you want to force by doing
peeling. Then, either (1) generate a loop in which 'p' is aligned and all
other accesses are not necessarily aligned, or (2) use loop versioning to
generate one loop in which all accesses are aligned, and another loop in
which only 'p' is necessarily aligned.
("Automatic Intra-Register Vectorization for the Intel Architecture",
Aart J.C. Bik, Milind Girkar, Paul M. Grey and Ximmin Tian, International
Journal of Parallel Programming, Vol. 30, No. 2, April 2002.)
Devising a cost model is the most critical aspect of this work. It will
guide us on which access to peel for, whether to use loop versioning, how
many versions to create, etc. The cost model will probably consist of
generic considerations as well as target specific considerations (on
powerpc for example, misaligned stores are more painful than misaligned
loads).
Here are the general steps involved in alignment enhancements:
-- original loop, before alignment analysis:
for (i=0; i<N; i++){
x = q[i]; # DR_MISALIGNMENT(q) = unknown
p[i] = y; # DR_MISALIGNMENT(p) = unknown
}
-- After vect_compute_data_refs_alignment:
for (i=0; i<N; i++){
x = q[i]; # DR_MISALIGNMENT(q) = 3
p[i] = y; # DR_MISALIGNMENT(p) = unknown
}
-- Possibility 1: we do loop versioning:
if (p is aligned) {
for (i=0; i<N; i++){ # loop 1A
x = q[i]; # DR_MISALIGNMENT(q) = 3
p[i] = y; # DR_MISALIGNMENT(p) = 0
}
}
else {
for (i=0; i<N; i++){ # loop 1B
x = q[i]; # DR_MISALIGNMENT(q) = 3
p[i] = y; # DR_MISALIGNMENT(p) = unaligned
}
}
-- Possibility 2: we do loop peeling:
for (i = 0; i < 3; i++){ # (scalar loop, not to be vectorized).
x = q[i];
p[i] = y;
}
for (i = 3; i < N; i++){ # loop 2A
x = q[i]; # DR_MISALIGNMENT(q) = 0
p[i] = y; # DR_MISALIGNMENT(p) = unknown
}
-- Possibility 3: combination of loop peeling and versioning:
for (i = 0; i < 3; i++){ # (scalar loop, not to be vectorized).
x = q[i];
p[i] = y;
}
if (p is aligned) {
for (i = 3; i<N; i++){ # loop 3A
x = q[i]; # DR_MISALIGNMENT(q) = 0
p[i] = y; # DR_MISALIGNMENT(p) = 0
}
}
else {
for (i = 3; i<N; i++){ # loop 3B
x = q[i]; # DR_MISALIGNMENT(q) = 0
p[i] = y; # DR_MISALIGNMENT(p) = unaligned
}
}
These loops are later passed to loop_transform to be vectorized. The
vectorizer will use the alignment information to guide the transformation
(whether to generate regular loads/stores, or with special handling for
misalignment). While cost model enhancements are expected in the future, the high level
view of the code at this time is as follows:
A) If there is a misaligned access then see if peeling to align
this access can make all data references satisfy
vect_supportable_dr_alignment. If so, update data structures
as needed and return true.
B) If peeling wasn't possible and there is a data reference with an
unknown misalignment that does not satisfy vect_supportable_dr_alignment
then see if loop versioning checks can be used to make all data
references satisfy vect_supportable_dr_alignment. If so, update
data structures as needed and return true.
C) If neither peeling nor versioning were successful then return false if
any data reference does not satisfy vect_supportable_dr_alignment.
D) Return true (all data references satisfy vect_supportable_dr_alignment).
Note, Possibility 3 above (which is peeling and versioning together) is not
being done at this time. (1) Peeling to force alignment.
(1.1) Decide whether to perform peeling, and how many iterations to peel:
Considerations:
+ How many accesses will become aligned due to the peeling
- How many accesses will become unaligned due to the peeling,
and the cost of misaligned accesses.
- The cost of peeling (the extra runtime checks, the increase
in code size). For interleaving, only the alignment of the first access
matters. For invariant accesses there is nothing to enhance.
Strided loads perform only component accesses, alignment is
irrelevant for them. Save info about DR in the hash table.
For multiple types, it is possible that the bigger type access
will have more than one peeling option. E.g., a loop with two
types: one of size (vector size / 4), and the other one of
size (vector size / 8). Vectorization factor will 8. If both
access are misaligned by 3, the first one needs one scalar
iteration to be aligned, and the second one needs 5. But the
the first one will be aligned also by peeling 5 scalar
iterations, and in that case both accesses will be aligned.
Hence, except for the immediate peeling amount, we also want
to try to add full vector size, while we don't exceed
vectorization factor.
We do this automtically for cost model, since we calculate cost
for every peeling option. Handle the aligned case. We may decide to align some other
access, making DR unaligned. Data-ref that was chosen for the case that all the
misalignments are unknown is not relevant anymore, since we
have a data-ref with known alignment. If we don't know any misalignment values, we prefer
peeling for data-ref that has the maximum number of data-refs
with the same alignment, unless the target prefers to align
stores over load. For data-refs with the same number of related
accesses prefer the one where the misalign
computation will be invariant in the outermost loop. If there are both known and unknown misaligned accesses in the
loop, we choose peeling amount according to the known
accesses. Check if we can possibly peel the loop.
Check if the target requires to prefer stores over loads, i.e., if
misaligned stores are more expensive than misaligned loads (taking
drs with same alignment into account). Calculate the penalty for leaving FIRST_STORE unaligned (by
aligning the load DR0). Calculate the penalty for leaving DR0 unaligned (by
aligning the FIRST_STORE). In case there are only loads with different unknown misalignments, use
peeling only if it may help to align other accesses in the loop. Peeling is possible, but there is no data access that is not supported
unless aligned. So we try to choose the best possible peeling. We should get here only if there are drs with known misalignment.
Choose the best peeling from the hash table.
Since it's known at compile time, compute the number of
iterations in the peeled loop (the peeling factor) for use in
updating DR_MISALIGNMENT values. The peeling factor is the
vectorization factor minus the misalignment as an element
count. For interleaved data access every iteration accesses all the
members of the group, therefore we divide the number of iterations
by the group size. Ensure that all data refs can be vectorized after the peel.
For interleaving, only the alignment of the first access
matters. Strided loads perform only component accesses, alignment is
irrelevant for them. (1.2) Update the DR_MISALIGNMENT of each data reference DR_i.
If the misalignment of DR_i is identical to that of dr0 then set
DR_MISALIGNMENT (DR_i) to zero. If the misalignment of DR_i and
dr0 are known at compile time then increment DR_MISALIGNMENT (DR_i)
by the peeling factor times the element size of DR_i (MOD the
vectorization factor times the size). Otherwise, the
misalignment of DR_i must be set to unknown. We've delayed passing the inside-loop peeling costs to the
target cost model until we were sure peeling would happen.
Do so now. (2) Versioning to force alignment.
Try versioning if:
1) optimize loop for speed
2) there is at least one unsupported misaligned data ref with an unknown
misalignment, and
3) all misaligned data refs with a known misalignment are supported, and
4) the number of runtime alignment checks is within reason. For interleaving, only the alignment of the first access
matters. Strided loads perform only component accesses, alignment is
irrelevant for them. The rightmost bits of an aligned address must be zeros.
Construct the mask needed for this test. For example,
GET_MODE_SIZE for the vector mode V4SI is 16 bytes so the
mask must be 15 = 0xf. FORNOW: use the same mask to test all potentially unaligned
references in the loop. The vectorizer currently supports
a single vector size, see the reference to
GET_MODE_NUNITS (TYPE_MODE (vectype)) where the
vectorization factor is computed. Versioning requires at least one misaligned data reference.
It can now be assumed that the data references in the statements
in LOOP_VINFO_MAY_MISALIGN_STMTS will be aligned in the version
of the loop being vectorized. Peeling and versioning can't be done together at this time.
This point is reached if neither peeling nor versioning is being done.
|
static |
Function vect_find_same_alignment_drs. Update group and alignment relations according to the chosen vectorization factor.
Loop-based vectorization and known data dependence.
Data-dependence analysis reports a distance vector of zero
for data-references that overlap only in the first iteration
but have different sign step (see PR45764).
So as a sanity check require equal DR_STEP. Same loop iteration.
Two references with distance zero have the same alignment.
References absu_hwi(), DR_IS_READ, DR_REF, DR_STEP, DR_STMT, dump_enabled_p(), dump_generic_expr(), dump_gimple_stmt(), dump_printf(), dump_printf_loc(), exact_log2(), HOST_WIDE_INT, loop::inner, vect_location, and vinfo_for_stmt().
|
static |
Calculate the cost of the memory access represented by DR.
References _vect_peel_info::count, _vect_peel_info::dr, _vect_peel_info::npeel, and _vect_peel_extended_info::peel_info.
Referenced by vect_peeling_hash_insert().
| tree vect_get_new_vect_var | ( | ) |
Function vect_get_new_vect_var. Returns a name for a new variable. The current naming scheme appends the prefix "vect_" or "vect_p" (depending on the value of VAR_KIND) to the name of vectorizer generated variables, and appends that to NAME if provided.
References DR_STEP, gimple_bb(), integer_zerop(), loop_preheader_edge(), nested_in_vect_loop_p(), and vinfo_for_stmt().
| tree vect_get_smallest_scalar_type | ( | gimple | stmt, |
| HOST_WIDE_INT * | lhs_size_unit, | ||
| HOST_WIDE_INT * | rhs_size_unit | ||
| ) |
Return the smallest scalar part of STMT. This is used to determine the vectype of the stmt. We generally set the vectype according to the type of the result (lhs). For stmts whose result-type is different than the type of the arguments (e.g., demotion, promotion), vectype will be reset appropriately (later). Note that we have to visit the smallest datatype in this function, because that determines the VF. If the smallest datatype in the loop is present only as the rhs of a promotion operation - we'd miss it. Such a case, where a variable of this datatype does not appear in the lhs anywhere in the loop, can only occur if it's an invariant: e.g.: 'int_x = (int) short_inv', which we'd expect to have been optimized away by invariant motion. However, we cannot rely on invariant motion to always take invariants out of the loop, and so in the case of promotion we also have to check the rhs. LHS_SIZE_UNIT and RHS_SIZE_UNIT contain the sizes of the corresponding types.
Referenced by vect_build_slp_tree_1().
| bool vect_grouped_load_supported | ( | ) |
Function vect_grouped_load_supported. Returns TRUE if even and odd permutations are supported, and FALSE otherwise.
vect_permute_load_chain requires the group size to be a power of two.
Check that the permutation is supported.
| bool vect_grouped_store_supported | ( | ) |
Function vect_grouped_store_supported. Returns TRUE if interleave high and interleave low permutations are supported, and FALSE otherwise.
vect_permute_store_chain requires the group size to be a power of two.
Check that the permutation is supported.
References gimple_assign_lhs(), gimple_bb(), nested_in_vect_loop_p(), and vinfo_for_stmt().
|
static |
@verbatim
Data References Analysis and Manipulation Utilities for Vectorization. Copyright (C) 2003-2013 Free Software Foundation, Inc. Contributed by Dorit Naishlos dorit@il.ibm.com and Ira Rosen irar@il.ibm.com
This file is part of GCC.
GCC is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3, or (at your option) any later version.
GCC is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with GCC; see the file COPYING3. If not see http://www.gnu.org/licenses/.
Need to include rtl.h, expr.h, etc. for optabs.
Return true if load- or store-lanes optab OPTAB is implemented for COUNT vectors of type VECTYPE. NAME is the name of OPTAB.
References targetm.
| bool vect_load_lanes_supported | ( | ) |
Return TRUE if vec_load_lanes is available for COUNT vectors of type VECTYPE.
|
static |
Insert DDR into LOOP_VINFO list of ddrs that may alias and need to be tested at run-time. Return TRUE if DDR was successfully inserted. Return false if versioning is not supported.
FORNOW: We don't support versioning with outer-loop vectorization.
FORNOW: We don't support creating runtime alias tests for non-constant
step.
References DDR_A, DDR_B, DR_REF, dump_generic_expr(), dump_printf(), dump_printf_loc(), and vect_location.
|
staticread |
Choose best peeling option by traversing peeling hash table and either choosing an option with the lowest cost (if cost model is enabled) or the option that aligns as many accesses as possible.
References DR_STMT, dump_enabled_p(), dump_printf_loc(), data_reference::stmt, vect_location, and vinfo_for_stmt().
| int vect_peeling_hash_get_lowest_cost | ( | _vect_peel_info ** | slot, |
| _vect_peel_extended_info * | min | ||
| ) |
Traverse peeling hash table and calculate cost for each peeling option. Find the one with the lowest cost.
For interleaving, only the alignment of the first access
matters. Prologue and epilogue costs are added to the target model later.
These costs depend only on the scalar iteration cost, the
number of peeling iterations finally chosen, and the number of
misaligned statements. So discard the information found here.
References _vect_peel_extended_info::body_cost_vec, _vect_peel_info::count, _vect_peel_info::dr, _vect_peel_extended_info::inside_cost, _vect_peel_info::npeel, _vect_peel_extended_info::outside_cost, _vect_peel_extended_info::peel_info, unlimited_cost_model(), and vect_peeling_hash_get_most_frequent().
| int vect_peeling_hash_get_most_frequent | ( | _vect_peel_info ** | slot, |
| _vect_peel_extended_info * | max | ||
| ) |
Traverse peeling hash table to find peeling option that aligns maximum number of data accesses.
References _vect_peel_extended_info::body_cost_vec, _vect_peel_info::dr, _vect_peel_extended_info::inside_cost, _vect_peel_info::npeel, _vect_peel_extended_info::outside_cost, and _vect_peel_extended_info::peel_info.
Referenced by vect_peeling_hash_get_lowest_cost().
|
static |
Insert DR into peeling hash table with NPEEL as key.
References _vect_peel_info::dr, DR_STMT, _vect_peel_info::npeel, vect_get_data_access_cost(), vect_update_misalignment_for_peel(), and vinfo_for_stmt().
|
static |
Function vect_permute_load_chain. Given a chain of interleaved loads in DR_CHAIN of LENGTH that must be a power of 2, generate extract_even/odd stmts to reorder the input data correctly. Return the final references for loads in RESULT_CHAIN. E.g., LENGTH is 4 and the scalar type is short, i.e., VF is 8. The input is 4 vectors each containing 8 elements. We assign a number to each element, the input sequence is: 1st vec: 0 1 2 3 4 5 6 7 2nd vec: 8 9 10 11 12 13 14 15 3rd vec: 16 17 18 19 20 21 22 23 4th vec: 24 25 26 27 28 29 30 31 The output sequence should be: 1st vec: 0 4 8 12 16 20 24 28 2nd vec: 1 5 9 13 17 21 25 29 3rd vec: 2 6 10 14 18 22 26 30 4th vec: 3 7 11 15 19 23 27 31 i.e., the first output vector should contain the first elements of each interleaving group, etc. We use extract_even/odd instructions to create such output. The input of each extract_even/odd operation is two vectors 1st vec 2nd vec 0 1 2 3 4 5 6 7 and the output is the vector of extracted even/odd elements. The output of extract_even will be: 0 2 4 6 and of extract_odd: 1 3 5 7 The permutation is done in log LENGTH stages. In each stage extract_even and extract_odd stmts are created for each pair of vectors in DR_CHAIN in their order. In our example, E1: extract_even (1st vec, 2nd vec) E2: extract_odd (1st vec, 2nd vec) E3: extract_even (3rd vec, 4th vec) E4: extract_odd (3rd vec, 4th vec) The output for the first stage will be: E1: 0 2 4 6 8 10 12 14 E2: 1 3 5 7 9 11 13 15 E3: 16 18 20 22 24 26 28 30 E4: 17 19 21 23 25 27 29 31 In order to proceed and create the correct sequence for the next stage (or for the correct output, if the second stage is the last one, as in our example), we first put the output of extract_even operation and then the output of extract_odd in RESULT_CHAIN (which is then copied to DR_CHAIN). The input for the second stage is: 1st vec (E1): 0 2 4 6 8 10 12 14 2nd vec (E3): 16 18 20 22 24 26 28 30 3rd vec (E2): 1 3 5 7 9 11 13 15 4th vec (E4): 17 19 21 23 25 27 29 31 The output of the second stage: E1: 0 4 8 12 16 20 24 28 E2: 2 6 10 14 18 22 26 30 E3: 1 5 9 13 17 21 25 29 E4: 3 7 11 15 19 23 27 31 And RESULT_CHAIN after reordering: 1st vec (E1): 0 4 8 12 16 20 24 28 2nd vec (E3): 1 5 9 13 17 21 25 29 3rd vec (E2): 2 6 10 14 18 22 26 30 4th vec (E4): 3 7 11 15 19 23 27 31.
data_ref = permute_even (first_data_ref, second_data_ref);
data_ref = permute_odd (first_data_ref, second_data_ref);
References dr_explicit_realign, dr_explicit_realign_optimized, DR_REF, DR_STEP, known_alignment_for_access_p(), not_size_aligned(), optab_handler(), and targetm.
| void vect_permute_store_chain | ( | vec< tree > | dr_chain, |
| unsigned int | length, | ||
| gimple | stmt, | ||
| gimple_stmt_iterator * | gsi, | ||
| vec< tree > * | result_chain | ||
| ) |
Function vect_permute_store_chain. Given a chain of interleaved stores in DR_CHAIN of LENGTH that must be a power of 2, generate interleave_high/low stmts to reorder the data correctly for the stores. Return the final references for stores in RESULT_CHAIN. E.g., LENGTH is 4 and the scalar type is short, i.e., VF is 8. The input is 4 vectors each containing 8 elements. We assign a number to each element, the input sequence is: 1st vec: 0 1 2 3 4 5 6 7 2nd vec: 8 9 10 11 12 13 14 15 3rd vec: 16 17 18 19 20 21 22 23 4th vec: 24 25 26 27 28 29 30 31 The output sequence should be: 1st vec: 0 8 16 24 1 9 17 25 2nd vec: 2 10 18 26 3 11 19 27 3rd vec: 4 12 20 28 5 13 21 30 4th vec: 6 14 22 30 7 15 23 31 i.e., we interleave the contents of the four vectors in their order. We use interleave_high/low instructions to create such output. The input of each interleave_high/low operation is two vectors: 1st vec 2nd vec 0 1 2 3 4 5 6 7 the even elements of the result vector are obtained left-to-right from the high/low elements of the first vector. The odd elements of the result are obtained left-to-right from the high/low elements of the second vector. The output of interleave_high will be: 0 4 1 5 and of interleave_low: 2 6 3 7 The permutation is done in log LENGTH stages. In each stage interleave_high and interleave_low stmts are created for each pair of vectors in DR_CHAIN, where the first argument is taken from the first half of DR_CHAIN and the second argument from it's second half. In our example, I1: interleave_high (1st vec, 3rd vec) I2: interleave_low (1st vec, 3rd vec) I3: interleave_high (2nd vec, 4th vec) I4: interleave_low (2nd vec, 4th vec) The output for the first stage is: I1: 0 16 1 17 2 18 3 19 I2: 4 20 5 21 6 22 7 23 I3: 8 24 9 25 10 26 11 27 I4: 12 28 13 29 14 30 15 31 The output of the second stage, i.e. the final result is: I1: 0 8 16 24 1 9 17 25 I2: 2 10 18 26 3 11 19 27 I3: 4 12 20 28 5 13 21 30 I4: 6 14 22 30 7 15 23 31.
Create interleaving stmt:
high = VEC_PERM_EXPR <vect1, vect2, {0, nelt, 1, nelt+1, ...}> Create interleaving stmt:
low = VEC_PERM_EXPR <vect1, vect2, {nelt/2, nelt*3/2, nelt/2+1,
nelt*3/2+1, ...}>
References build_int_cst(), copy_ssa_name(), DR_REF, gimple_assign_lhs(), gimple_assign_set_lhs(), gimple_build_assign_with_ops(), gsi_insert_before(), gsi_insert_on_edge_immediate(), GSI_SAME_STMT, HOST_WIDE_INT, make_ssa_name(), reference_alias_ptr_type(), vect_create_data_ref_ptr(), and vect_create_destination_var().
| bool vect_prune_runtime_alias_test_list | ( | ) |
Function vect_prune_runtime_alias_test_list. Prune a list of ddrs to be tested at run-time by versioning for alias. Return FALSE if resulting list of ddrs is longer then allowed by PARAM_VECT_MAX_VERSION_FOR_ALIAS_CHECKS, otherwise return TRUE.
| void vect_record_grouped_load_vectors | ( | ) |
RESULT_CHAIN contains the output of a group of grouped loads that were generated as part of the vectorization of STMT. Assign the statement for each vector to the associated scalar statement.
Put a permuted data-ref in the VECTORIZED_STMT field.
Since we scan the chain starting from it's first node, their order
corresponds the order of data-refs in RESULT_CHAIN. Skip the gaps. Loads created for the gaps will be removed by dead
code elimination pass later. No need to check for the first stmt in
the group, since it always exists.
GROUP_GAP is the number of steps in elements from the previous
access (if there is no gap GROUP_GAP is 1). We skip loads that
correspond to the gaps. We assume that if VEC_STMT is not NULL, this is a case of multiple
copies, and we put the new vector statement in the first available
RELATED_STMT. If NEXT_STMT accesses the same DR as the previous statement,
put the same TMP_DATA_REF as its vectorized statement; otherwise
get the next data-ref from RESULT_CHAIN.
|
static |
Check if data references pointed by DR_I and DR_J are same or belong to same interleaving group. Return FALSE if drs are different, otherwise return TRUE.
| tree vect_setup_realignment | ( | gimple | stmt, |
| gimple_stmt_iterator * | gsi, | ||
| tree * | realignment_token, | ||
| enum dr_alignment_support | alignment_support_scheme, | ||
| tree | init_addr, | ||
| struct loop ** | at_loop | ||
| ) |
Function vect_setup_realignment
This function is called when vectorizing an unaligned load using
the dr_explicit_realign[_optimized] scheme.
This function generates the following code at the loop prolog:
p = initial_addr;
x msq_init = *(floor(p)); # prolog load
realignment_token = call target_builtin;
loop:
x msq = phi (msq_init, ---)
The stmts marked with x are generated only for the case of
dr_explicit_realign_optimized.
The code above sets up a new (vector) pointer, pointing to the first
location accessed by STMT, and a "floor-aligned" load using that pointer.
It also generates code to compute the "realignment-token" (if the relevant
target hook was defined), and creates a phi-node at the loop-header bb
whose arguments are the result of the prolog-load (created by this
function) and the result of a load that takes place in the loop (to be
created by the caller to this function).
For the case of dr_explicit_realign_optimized:
The caller to this function uses the phi-result (msq) to create the
realignment code inside the loop, and sets up the missing phi argument,
as follows:
loop:
msq = phi (msq_init, lsq)
lsq = *(floor(p')); # load in loop
result = realign_load (msq, lsq, realignment_token);
For the case of dr_explicit_realign:
loop:
msq = *(floor(p)); # load in loop
p' = p + (VS-1);
lsq = *(floor(p')); # load in loop
result = realign_load (msq, lsq, realignment_token);
Input:
STMT - (scalar) load stmt to be vectorized. This load accesses
a memory location that may be unaligned.
BSI - place where new code is to be inserted.
ALIGNMENT_SUPPORT_SCHEME - which of the two misalignment handling schemes
is used.
Output:
REALIGNMENT_TOKEN - the result of a call to the builtin_mask_for_load
target hook, if defined.
Return value - the result of the loop-header phi node. We need to generate three things:
1. the misalignment computation
2. the extra vector load (for the optimized realignment scheme).
3. the phi node for the two vectors from which the realignment is
done (for the optimized realignment scheme). 1. Determine where to generate the misalignment computation.
If INIT_ADDR is NULL_TREE, this indicates that the misalignment
calculation will be generated by this function, outside the loop (in the
preheader). Otherwise, INIT_ADDR had already been computed for us by the
caller, inside the loop.
Background: If the misalignment remains fixed throughout the iterations of
the loop, then both realignment schemes are applicable, and also the
misalignment computation can be done outside LOOP. This is because we are
vectorizing LOOP, and so the memory accesses in LOOP advance in steps that
are a multiple of VS (the Vector Size), and therefore the misalignment in
different vectorized LOOP iterations is always the same.
The problem arises only if the memory access is in an inner-loop nested
inside LOOP, which is now being vectorized using outer-loop vectorization.
This is the only case when the misalignment of the memory access may not
remain fixed throughout the iterations of the inner-loop (as explained in
detail in vect_supportable_dr_alignment). In this case, not only is the
optimized realignment scheme not applicable, but also the misalignment
computation (and generation of the realignment token that is passed to
REALIGN_LOAD) have to be done inside the loop.
In short, INIT_ADDR indicates whether we are in a COMPUTE_IN_LOOP mode
or not, which in turn determines if the misalignment is computed inside
the inner-loop, or outside LOOP. 2. Determine where to generate the extra vector load.
For the optimized realignment scheme, instead of generating two vector
loads in each iteration, we generate a single extra vector load in the
preheader of the loop, and in each iteration reuse the result of the
vector load from the previous iteration. In case the memory access is in
an inner-loop nested inside LOOP, which is now being vectorized using
outer-loop vectorization, we need to determine whether this initial vector
load should be generated at the preheader of the inner-loop, or can be
generated at the preheader of LOOP. If the memory access has no evolution
in LOOP, it can be generated in the preheader of LOOP. Otherwise, it has
to be generated inside LOOP (in the preheader of the inner-loop). 3. For the case of the optimized realignment, create the first vector
load at the loop preheader. Create msq_init = *(floor(p1)) in the loop preheader
4. Create realignment token using a target builtin, if available.
It is done either inside the containing loop, or before LOOP (as
determined above). Compute INIT_ADDR - the initial addressed accessed by this memref.
Generate the INIT_ADDR computation outside LOOP.
Generate the misalignment computation outside LOOP.
The result of the CALL_EXPR to this builtin is determined from
the value of the parameter and no global variables are touched
which makes the builtin a "const" function. Requiring the
builtin to have the "const" attribute makes it unnecessary
to call mark_call_clobbered. 5. Create msq = phi <msq_init, lsq> in loop
References dump_enabled_p(), dump_printf_loc(), and vect_location.
|
static |
Function vect_slp_analyze_data_ref_dependence. Return TRUE if there (might) exist a dependence between a memory-reference DRA and a memory-reference DRB. When versioning for alias may check a dependence at run-time, return FALSE. Adjust *MAX_VF according to the data dependence.
We need to check dependences of statements marked as unvectorizable
as well, they still can prohibit vectorization. Independent data accesses.
Read-read is OK.
If dra and drb are part of the same interleaving chain consider
them independent. Unknown data dependence.
We do not vectorize basic blocks with write-write dependencies.
Check that it's not a load-after-store dependence.
Do not vectorize basic blocks with write-write dependences.
Check dependence between DRA and DRB for basic block vectorization.
If the accesses share same bases and offsets, we can compare their initial
constant offsets to decide whether they differ or not. In case of a read-
write dependence we check that the load is before the store to ensure that
vectorization will not change the order of the accesses. Check that the data-refs have same bases and offsets. If not, we can't
determine if they are dependent. Check the types.
Two different locations - no dependence.
We have a read-write dependence. Check that the load is before the store.
When we vectorize basic blocks, vector load can be only before
corresponding scalar load, and vector store can be only after its
corresponding scalar store. So the order of the acceses is preserved in
case the load is before the store.
References DR_IS_WRITE, DR_REF, DR_STMT, dump_enabled_p(), dump_generic_expr(), dump_printf(), dump_printf_loc(), get_earlier_stmt(), vect_location, and vinfo_for_stmt().
| bool vect_slp_analyze_data_ref_dependences | ( | ) |
Function vect_analyze_data_ref_dependences. Examine all the data references in the basic-block, and make sure there do not exist any data dependences between them. Set *MAX_VF according to the maximum vectorization factor the data dependences allow.
| bool vect_store_lanes_supported | ( | ) |
Return TRUE if vec_store_lanes is available for COUNT vectors of type VECTYPE.
| enum dr_alignment_support vect_supportable_dr_alignment | ( | struct data_reference * | dr, |
| bool | check_aligned_accesses | ||
| ) |
Return whether the data reference DR is supported with respect to its alignment. If CHECK_ALIGNED_ACCESSES is TRUE, check if the access is supported even it is aligned, i.e., check if it is possible to vectorize it with different alignment.
Possibly unaligned access.
We can choose between using the implicit realignment scheme (generating
a misaligned_move stmt) and the explicit realignment scheme (generating
aligned loads with a REALIGN_LOAD). There are two variants to the
explicit realignment scheme: optimized, and unoptimized.
We can optimize the realignment only if the step between consecutive
vector loads is equal to the vector size. Since the vector memory
accesses advance in steps of VS (Vector Size) in the vectorized loop, it
is guaranteed that the misalignment amount remains the same throughout the
execution of the vectorized loop. Therefore, we can create the
"realignment token" (the permutation mask that is passed to REALIGN_LOAD)
at the loop preheader.
However, in the case of outer-loop vectorization, when vectorizing a
memory access in the inner-loop nested within the LOOP that is now being
vectorized, while it is guaranteed that the misalignment of the
vectorized memory access will remain the same in different outer-loop
iterations, it is *not* guaranteed that is will remain the same throughout
the execution of the inner-loop. This is because the inner-loop advances
with the original scalar step (and not in steps of VS). If the inner-loop
step happens to be a multiple of VS, then the misalignment remains fixed
and we can use the optimized realignment scheme. For example:
for (i=0; i<N; i++)
for (j=0; j<M; j++)
s += a[i+j];
When vectorizing the i-loop in the above example, the step between
consecutive vector loads is 1, and so the misalignment does not remain
fixed across the execution of the inner-loop, and the realignment cannot
be optimized (as illustrated in the following pseudo vectorized loop):
for (i=0; i<N; i+=4)
for (j=0; j<M; j++){
vs += vp[i+j]; // misalignment of &vp[i+j] is {0,1,2,3,0,1,2,3,...}
// when j is {0,1,2,3,4,5,6,7,...} respectively.
// (assuming that we start from an aligned address).
}
We therefore have to use the unoptimized realignment scheme:
for (i=0; i<N; i+=4)
for (j=k; j<M; j+=4)
vs += vp[i+j]; // misalignment of &vp[i+j] is always k (assuming
// that the misalignment of the initial address is
// 0).
The loop can then be vectorized as follows:
for (k=0; k<4; k++){
rt = get_realignment_token (&vp[k]);
for (i=0; i<N; i+=4){
v1 = vp[i+k];
for (j=k; j<M; j+=4){
v2 = vp[i+j+VS-1];
va = REALIGN_LOAD <v1,v2,rt>;
vs += va;
v1 = v2;
}
}
} Can't software pipeline the loads, but can at least do them.
Unsupported.
Referenced by vect_build_slp_tree_1(), and vect_update_misalignment_for_peel().
| void vect_transform_grouped_load | ( | gimple | stmt, |
| vec< tree > | dr_chain, | ||
| int | size, | ||
| gimple_stmt_iterator * | gsi | ||
| ) |
@verbatim
Function vect_transform_grouped_load.
Given a chain of input interleaved data-refs (in DR_CHAIN), build statements to perform their permutation and ascribe the result vectorized statements to the scalar statements.
DR_CHAIN contains input data-refs that are a part of the interleaving.
RESULT_CHAIN is the output of vect_permute_load_chain, it contains permuted
vectors, that are ready for vector computation.
References targetm.
|
static |
Function vect_update_misalignment_for_peel
DR - the data reference whose misalignment is to be adjusted.
DR_PEEL - the data reference whose misalignment is being made
zero in the vector loop by the peel.
NPEEL - the number of iterations in the peel loop if the misalignment
of DR_PEEL is known at compile time. For interleaved data accesses the step in the loop must be multiplied by
the size of the interleaving group. It can be assumed that the data refs with the same alignment as dr_peel
are aligned in the vector loop.
References dr_aligned, DR_IS_READ, DR_REF, DR_STMT, dump_enabled_p(), dump_generic_expr(), dump_printf(), dump_printf_loc(), vect_location, vect_supportable_dr_alignment(), and vinfo_for_stmt().
Referenced by vect_peeling_hash_insert().
| bool vect_verify_datarefs_alignment | ( | ) |
Function vect_verify_datarefs_alignment Return TRUE if all data references in the loop can be handled with respect to alignment.
For interleaving, only the alignment of the first access matters.
Skip statements marked as not vectorizable. Strided loads perform only component accesses, alignment is
irrelevant for them.
|
static |
If address ranges represented by DDR_I and DDR_J are equal, return TRUE, otherwise return FALSE.
|
static |
Function vector_alignment_reachable_p Return true if vector alignment for DR is reachable by peeling a few loop iterations. Return false otherwise.
For interleaved access we peel only if number of iterations in
the prolog loop ({VF - misalignment}), is a multiple of the
number of the interleaved accesses. FORNOW: handle only known alignment.
If misalignment is known at the compile time then allow peeling
only if natural alignment is reachable through peeling.
1.8.1.1