Re: [PATCH][2/3] Vectorize inductions that are live after the loop
On Fri, May 27, 2016 at 11:09 AM, Alan Hayward wrote:
> This patch is a reworking of the previous vectorize inductions that are
> live
> after the loop patch.
> It now supports SLP and an optimisation has been moved to patch [3/3].
>
>
> Stmts which are live (ie: defined inside a loop and then used after the
> loop)
> are not currently supported by the vectorizer. In many cases
> vectorization can
> still occur because the SCEV cprop pass will hoist the definition of the
> stmt
> outside of the loop before the vectorizor pass. However, there are various
> cases SCEV cprop cannot hoist, for example:
> for (i = 0; i < n; ++i)
> {
> ret = x[i];
> x[i] = i;
> }
>return i;
>
> Currently stmts are marked live using a bool, and the relevant state using
> an
> enum. Both these states are propagated to the definition of all uses of the
> stmt. Also, a stmt can be live but not relevant.
>
> This patch vectorizes a live stmt definition normally within the loop and
> then
> after the loop uses BIT_FIELD_REF to extract the final scalar value from
> the
> vector.
>
> This patch adds a new relevant state (vect_used_only_live) for when a stmt
> is
> used only outside the loop. The relevant state is still propagated to all
> it's
> uses, but the live bool is not (this ensures that
> vectorizable_live_operation
> is only called with stmts that really are live).
>
> Tested on x86 and aarch64.
+ /* If STMT is a simple assignment and its inputs are invariant, then it can
+ remain in place, unvectorized. The original last scalar value that it
+ computes will be used. */
+ if (is_simple_and_all_uses_invariant (stmt, loop_vinfo))
{
so we can't use STMT_VINFO_RELEVANT or so? I thought we somehow
mark stmts we don't vectorize in the end.
+ lhs = (is_a (stmt)) ? gimple_phi_result (stmt)
+ : gimple_get_lhs (stmt);
+ lhs_type = TREE_TYPE (lhs);
+
+ /* Find all uses of STMT outside the loop. */
+ auto_vec worklist;
+ FOR_EACH_IMM_USE_STMT (use_stmt, imm_iter, lhs)
+{
+ basic_block bb = gimple_bb (use_stmt);
+
+ if (!flow_bb_inside_loop_p (loop, bb))
+ worklist.safe_push (use_stmt);
}
+ gcc_assert (!worklist.is_empty ());
as we are in loop-closed SSA there should be exactly one such use...?
+ /* Get the correct slp vectorized stmt. */
+ vec_oprnds.create (num_vec);
+ vect_get_slp_vect_defs (slp_node, &vec_oprnds);
As you look at the vectorized stmt you can directly use the SLP_TREE_VEC_STMTS
array (the stmts lhs, of course), no need to export this function.
The rest of the changes look ok to me.
Thanks,
Richard.
> gcc/
> * tree-vect-loop.c (vect_analyze_loop_operations): Allow live
> stmts.
> (vectorizable_reduction): Check for new relevant state.
> (vectorizable_live_operation): vectorize live stmts using
> BIT_FIELD_REF. Remove special case for gimple assigns stmts.
> * tree-vect-stmts.c (is_simple_and_all_uses_invariant): New
> function.
> (vect_stmt_relevant_p): Check for stmts which are only used live.
> (process_use): Use of a stmt does not inherit it's live value.
> (vect_mark_stmts_to_be_vectorized): Simplify relevance inheritance.
> (vect_analyze_stmt): Check for new relevant state.
> *tree-vect-slp.c (vect_get_slp_vect_defs): Make global
> *tree-vectorizer.h (vect_relevant): New entry for a stmt which is
> used
> outside the loop, but not inside it.
>
> testsuite/
> * gcc.dg/tree-ssa/pr64183.c: Ensure test does not vectorize.
> * testsuite/gcc.dg/vect/no-scevccp-vect-iv-2.c: Remove xfail.
> * gcc.dg/vect/vect-live-1.c: New test.
> * gcc.dg/vect/vect-live-2.c: New test.
> * gcc.dg/vect/vect-live-3.c: New test.
> * gcc.dg/vect/vect-live-4.c: New test.
> * gcc.dg/vect/vect-live-5.c: New test.
> * gcc.dg/vect/vect-live-slp-1.c: New test.
> * gcc.dg/vect/vect-live-slp-2.c: New test.
> * gcc.dg/vect/vect-live-slp-3.c: New test.
> * gcc.dg/vect/vect-live-slp-4.c: New test.
>
>
>
> Alan.
>
Re: [PATCH][2/3] Vectorize inductions that are live after the loop
On 27/05/2016 12:41, "Richard Biener" wrote:
>On Fri, May 27, 2016 at 11:09 AM, Alan Hayward
>wrote:
>> This patch is a reworking of the previous vectorize inductions that are
>> live
>> after the loop patch.
>> It now supports SLP and an optimisation has been moved to patch [3/3].
>>
>>
>> Stmts which are live (ie: defined inside a loop and then used after the
>> loop)
>> are not currently supported by the vectorizer. In many cases
>> vectorization can
>> still occur because the SCEV cprop pass will hoist the definition of the
>> stmt
>> outside of the loop before the vectorizor pass. However, there are
>>various
>> cases SCEV cprop cannot hoist, for example:
>> for (i = 0; i < n; ++i)
>> {
>> ret = x[i];
>> x[i] = i;
>> }
>>return i;
>>
>> Currently stmts are marked live using a bool, and the relevant state
>>using
>> an
>> enum. Both these states are propagated to the definition of all uses of
>>the
>> stmt. Also, a stmt can be live but not relevant.
>>
>> This patch vectorizes a live stmt definition normally within the loop
>>and
>> then
>> after the loop uses BIT_FIELD_REF to extract the final scalar value from
>> the
>> vector.
>>
>> This patch adds a new relevant state (vect_used_only_live) for when a
>>stmt
>> is
>> used only outside the loop. The relevant state is still propagated to
>>all
>> it's
>> uses, but the live bool is not (this ensures that
>> vectorizable_live_operation
>> is only called with stmts that really are live).
>>
>> Tested on x86 and aarch64.
>
>+ /* If STMT is a simple assignment and its inputs are invariant, then
>it can
>+ remain in place, unvectorized. The original last scalar value that
>it
>+ computes will be used. */
>+ if (is_simple_and_all_uses_invariant (stmt, loop_vinfo))
> {
>
>so we can't use STMT_VINFO_RELEVANT or so? I thought we somehow
>mark stmts we don't vectorize in the end.
It’s probably worth making clear that this check exists in the current
GCC head - today vectorize_live_operation only supports the
simple+invariant
case and the SSE2 case.
My patch simply moved the simple+invariant code into the new function
is_simple_and_all_uses_invariant.
Looking at this again, I think what we really care about is….
*If the stmt is live but not relevant, we need to mark it to ensure it is
vectorised.
*If a stmt is simple+invariant then a live usage of it can either use the
scalar or vectorized version.
So for a live stmt:
*If it is simple+invariant and not relevant, then it is more optimal to
use the
scalar version.
*If it is simple+invariant and relevant then it is more optimal to use the
vectorized version.
*If it is not simple+invariant then we must always use the vectorized
version.
Therefore, the patch as it stands is correct but not optimal. In patch 3/3
for
the code above (vectorize_live_operation) I can change the check to if not
relevant then assert that it is not simple+invariant and return true.
>
>+ lhs = (is_a (stmt)) ? gimple_phi_result (stmt)
>+ : gimple_get_lhs (stmt);
>+ lhs_type = TREE_TYPE (lhs);
>+
>+ /* Find all uses of STMT outside the loop. */
>+ auto_vec worklist;
>+ FOR_EACH_IMM_USE_STMT (use_stmt, imm_iter, lhs)
>+{
>+ basic_block bb = gimple_bb (use_stmt);
>+
>+ if (!flow_bb_inside_loop_p (loop, bb))
>+ worklist.safe_push (use_stmt);
> }
>+ gcc_assert (!worklist.is_empty ());
>
>as we are in loop-closed SSA there should be exactly one such use...?
Yes, I should change this to assert that worklist is of length 1.
>
>+ /* Get the correct slp vectorized stmt. */
>+ vec_oprnds.create (num_vec);
>+ vect_get_slp_vect_defs (slp_node, &vec_oprnds);
>
>As you look at the vectorized stmt you can directly use the
>SLP_TREE_VEC_STMTS
>array (the stmts lhs, of course), no need to export this function.
Ok, I can change this.
>
>The rest of the changes look ok to me.
Does that include PATCH 1/3 ?
>
>Thanks,
>Richard.
>
>
>> gcc/
>> * tree-vect-loop.c (vect_analyze_loop_operations): Allow live
>> stmts.
>> (vectorizable_reduction): Check for new relevant state.
>> (vectorizable_live_operation): vectorize live stmts using
>> BIT_FIELD_REF. Remove special case for gimple assigns stmts.
>> * tree-vect-stmts.c (is_simple_and_all_uses_invariant): New
>> function.
>> (vect_stmt_relevant_p): Check for stmts which are only used
>>live.
>> (process_use): Use of a stmt does not inherit it's live value.
>> (vect_mark_stmts_to_be_vectorized): Simplify relevance
>>inheritance.
>> (vect_analyze_stmt): Check for new relevant state.
>> *tree-vect-slp.c (vect_get_slp_vect_defs): Make global
>> *tree-vectorizer.h (vect_relevant): New entry for a stmt which
>>is
>> used
>> outside the loop, but not inside it.
>>
>> testsuite/
>> * gcc.dg/tree-ssa/pr64183.c: Ensure test does not vectorize.
>> * testsuite/gcc.dg/vect/no-scevccp-vect-iv-2.c: Rem
Re: [PATCH][2/3] Vectorize inductions that are live after the loop
On Fri, May 27, 2016 at 5:12 PM, Alan Hayward wrote:
>
> On 27/05/2016 12:41, "Richard Biener" wrote:
>
>>On Fri, May 27, 2016 at 11:09 AM, Alan Hayward
>>wrote:
>>> This patch is a reworking of the previous vectorize inductions that are
>>> live
>>> after the loop patch.
>>> It now supports SLP and an optimisation has been moved to patch [3/3].
>>>
>>>
>>> Stmts which are live (ie: defined inside a loop and then used after the
>>> loop)
>>> are not currently supported by the vectorizer. In many cases
>>> vectorization can
>>> still occur because the SCEV cprop pass will hoist the definition of the
>>> stmt
>>> outside of the loop before the vectorizor pass. However, there are
>>>various
>>> cases SCEV cprop cannot hoist, for example:
>>> for (i = 0; i < n; ++i)
>>> {
>>> ret = x[i];
>>> x[i] = i;
>>> }
>>>return i;
>>>
>>> Currently stmts are marked live using a bool, and the relevant state
>>>using
>>> an
>>> enum. Both these states are propagated to the definition of all uses of
>>>the
>>> stmt. Also, a stmt can be live but not relevant.
>>>
>>> This patch vectorizes a live stmt definition normally within the loop
>>>and
>>> then
>>> after the loop uses BIT_FIELD_REF to extract the final scalar value from
>>> the
>>> vector.
>>>
>>> This patch adds a new relevant state (vect_used_only_live) for when a
>>>stmt
>>> is
>>> used only outside the loop. The relevant state is still propagated to
>>>all
>>> it's
>>> uses, but the live bool is not (this ensures that
>>> vectorizable_live_operation
>>> is only called with stmts that really are live).
>>>
>>> Tested on x86 and aarch64.
>>
>>+ /* If STMT is a simple assignment and its inputs are invariant, then
>>it can
>>+ remain in place, unvectorized. The original last scalar value that
>>it
>>+ computes will be used. */
>>+ if (is_simple_and_all_uses_invariant (stmt, loop_vinfo))
>> {
>>
>>so we can't use STMT_VINFO_RELEVANT or so? I thought we somehow
>>mark stmts we don't vectorize in the end.
>
> It’s probably worth making clear that this check exists in the current
> GCC head - today vectorize_live_operation only supports the
> simple+invariant
> case and the SSE2 case.
> My patch simply moved the simple+invariant code into the new function
> is_simple_and_all_uses_invariant.
Ah, didn't notice this.
> Looking at this again, I think what we really care about is….
> *If the stmt is live but not relevant, we need to mark it to ensure it is
> vectorised.
> *If a stmt is simple+invariant then a live usage of it can either use the
> scalar or vectorized version.
>
> So for a live stmt:
> *If it is simple+invariant and not relevant, then it is more optimal to
> use the
> scalar version.
> *If it is simple+invariant and relevant then it is more optimal to use the
> vectorized version.
> *If it is not simple+invariant then we must always use the vectorized
> version.
So, if ! relevant (aka not vectorized) use the scalar version. Otherwise
use the vectorized version. The case we fail to handle is a live but not
relevant computation derived from a vectorized stmt (the !invariant and
!relevant case). This case should be handled by sinking the computation
up to the vectorized stmt to the exit and handling the "last" live operation
by using the vectorized def. In fact stmt sinking should have performed
this sinking already (so a check and not vectorizing this case just in
case that didn't happen is fine I think)
> Therefore, the patch as it stands is correct but not optimal. In patch 3/3
> for
> the code above (vectorize_live_operation) I can change the check to if not
> relevant then assert that it is not simple+invariant and return true.
Sounds good.
>
>
>>
>>+ lhs = (is_a (stmt)) ? gimple_phi_result (stmt)
>>+ : gimple_get_lhs (stmt);
>>+ lhs_type = TREE_TYPE (lhs);
>>+
>>+ /* Find all uses of STMT outside the loop. */
>>+ auto_vec worklist;
>>+ FOR_EACH_IMM_USE_STMT (use_stmt, imm_iter, lhs)
>>+{
>>+ basic_block bb = gimple_bb (use_stmt);
>>+
>>+ if (!flow_bb_inside_loop_p (loop, bb))
>>+ worklist.safe_push (use_stmt);
>> }
>>+ gcc_assert (!worklist.is_empty ());
>>
>>as we are in loop-closed SSA there should be exactly one such use...?
>
> Yes, I should change this to assert that worklist is of length 1.
>
>>
>>+ /* Get the correct slp vectorized stmt. */
>>+ vec_oprnds.create (num_vec);
>>+ vect_get_slp_vect_defs (slp_node, &vec_oprnds);
>>
>>As you look at the vectorized stmt you can directly use the
>>SLP_TREE_VEC_STMTS
>>array (the stmts lhs, of course), no need to export this function.
>
> Ok, I can change this.
>
>>
>>The rest of the changes look ok to me.
>
> Does that include PATCH 1/3 ?
I don't like how 1/3 ends up looking :/ So what was the alternative again?
I looked into 1/3 and what it takes to remove the 'stmt' argument and
instead pass in a vect_def_type. It's a bit twisted and just adding another
argument (the loop_vinfo) doesn't help th
Re: [PATCH][2/3] Vectorize inductions that are live after the loop
On 30/05/2016 14:22, "Richard Biener" wrote:
>On Fri, May 27, 2016 at 5:12 PM, Alan Hayward
>wrote:
>>
>> On 27/05/2016 12:41, "Richard Biener"
>>wrote:
>>
>>>On Fri, May 27, 2016 at 11:09 AM, Alan Hayward
>>>wrote:
>>
>>>
>>>The rest of the changes look ok to me.
>>
>> Does that include PATCH 1/3 ?
>
>I don't like how 1/3 ends up looking :/ So what was the alternative
>again?
>I looked into 1/3 and what it takes to remove the 'stmt' argument and
>instead pass in a vect_def_type. It's a bit twisted and just adding
>another
>argument (the loop_vinfo) doesn't help things here.
>
>So - instead of 1/3 you might want to split out a function
>
>tree
>vect_get_vec_def_for_operand_1 (gimple *def_stmt, enum vect_def_type
>dt, tree vectype)
>{
> switch (dt)
>{
>...
>}
>}
>
>and for constant/external force vectype != NULL.
I’m still a little confused as to exactly what you want here.
From your two comments I think you wanted me to completely remove the
boolean type check and the vect_init_vector call. But if I remove that
then other code paths will break.
However, I’ve just realised that in vectorized_live_operation I already
have the def stmt and I can easily get hold of dt from STMT_VINFO_DEF_TYPE.
Which means I can call vect_get_vec_def_for_operand_1 from
vectorized_live_operation.
I’ve put together a version where I have:
tree
vect_get_vec_def_for_operand_1 (gimple *def_stmt, enum vect_def_type dt)
{
switch (dt)
{
case vect_internal_def || vect_external_def:
gcc_unreachable ()
.. code for for all other cases..
}
}
/* Used by existing code */
tree
vect_get_vec_def_for_operand (tree op, gimple *stmt, tree vectype)
{
vect_is_simple_use(op, loop_vinfo, &def_stmt, &dt); ..and the dump code
If dt == internal_def || vect_external_def:
.. Check for BOOLEAN_TYPE ..
return vect_init_vector (stmt, op, vector_type, NULL);
else
vect_get_vec_def_for_operand_1 (def_stmt, dt)
}
Does that look better?
Alan.
Re: [PATCH][2/3] Vectorize inductions that are live after the loop
On Wed, Jun 1, 2016 at 10:46 AM, Alan Hayward wrote:
>
>
> On 30/05/2016 14:22, "Richard Biener" wrote:
>
>>On Fri, May 27, 2016 at 5:12 PM, Alan Hayward
>>wrote:
>>>
>>> On 27/05/2016 12:41, "Richard Biener"
>>>wrote:
>>>
On Fri, May 27, 2016 at 11:09 AM, Alan Hayward
wrote:
>
>>>
The rest of the changes look ok to me.
>>>
>>> Does that include PATCH 1/3 ?
>>
>>I don't like how 1/3 ends up looking :/ So what was the alternative
>>again?
>>I looked into 1/3 and what it takes to remove the 'stmt' argument and
>>instead pass in a vect_def_type. It's a bit twisted and just adding
>>another
>>argument (the loop_vinfo) doesn't help things here.
>>
>>So - instead of 1/3 you might want to split out a function
>>
>>tree
>>vect_get_vec_def_for_operand_1 (gimple *def_stmt, enum vect_def_type
>>dt, tree vectype)
>>{
>> switch (dt)
>>{
>>...
>>}
>>}
>>
>>and for constant/external force vectype != NULL.
>
> I’m still a little confused as to exactly what you want here.
>
> From your two comments I think you wanted me to completely remove the
> boolean type check and the vect_init_vector call. But if I remove that
> then other code paths will break.
>
> However, I’ve just realised that in vectorized_live_operation I already
> have the def stmt and I can easily get hold of dt from STMT_VINFO_DEF_TYPE.
> Which means I can call vect_get_vec_def_for_operand_1 from
> vectorized_live_operation.
>
> I’ve put together a version where I have:
>
> tree
> vect_get_vec_def_for_operand_1 (gimple *def_stmt, enum vect_def_type dt)
> {
>
> switch (dt)
> {
>case vect_internal_def || vect_external_def:
> gcc_unreachable ()
>
>.. code for for all other cases..
> }
> }
>
> /* Used by existing code */
> tree
> vect_get_vec_def_for_operand (tree op, gimple *stmt, tree vectype)
> {
> vect_is_simple_use(op, loop_vinfo, &def_stmt, &dt); ..and the dump code
>
>
> If dt == internal_def || vect_external_def:
> .. Check for BOOLEAN_TYPE ..
> return vect_init_vector (stmt, op, vector_type, NULL);
>
> else
> vect_get_vec_def_for_operand_1 (def_stmt, dt)
> }
>
>
> Does that look better?
Yes!
Thanks,
Richard.
>
> Alan.
>
>
>
>
Re: [PATCH][2/3] Vectorize inductions that are live after the loop
On 01/06/2016 10:51, "Richard Biener" wrote:
>On Wed, Jun 1, 2016 at 10:46 AM, Alan Hayward
>wrote:
>>
>>
>> On 30/05/2016 14:22, "Richard Biener"
>>wrote:
>>
>>>On Fri, May 27, 2016 at 5:12 PM, Alan Hayward
>>>wrote:
On 27/05/2016 12:41, "Richard Biener"
wrote:
>On Fri, May 27, 2016 at 11:09 AM, Alan Hayward
>wrote:
>>
>
>The rest of the changes look ok to me.
Does that include PATCH 1/3 ?
>>>
>>>I don't like how 1/3 ends up looking :/ So what was the alternative
>>>again?
>>>I looked into 1/3 and what it takes to remove the 'stmt' argument and
>>>instead pass in a vect_def_type. It's a bit twisted and just adding
>>>another
>>>argument (the loop_vinfo) doesn't help things here.
>>>
>>>So - instead of 1/3 you might want to split out a function
>>>
>>>tree
>>>vect_get_vec_def_for_operand_1 (gimple *def_stmt, enum vect_def_type
>>>dt, tree vectype)
>>>{
>>> switch (dt)
>>>{
>>>...
>>>}
>>>}
>>>
>>>and for constant/external force vectype != NULL.
>>
>> I’m still a little confused as to exactly what you want here.
>>
>> From your two comments I think you wanted me to completely remove the
>> boolean type check and the vect_init_vector call. But if I remove that
>> then other code paths will break.
>>
>> However, I’ve just realised that in vectorized_live_operation I already
>> have the def stmt and I can easily get hold of dt from
>>STMT_VINFO_DEF_TYPE.
>> Which means I can call vect_get_vec_def_for_operand_1 from
>> vectorized_live_operation.
>>
>> I’ve put together a version where I have:
>>
>> tree
>> vect_get_vec_def_for_operand_1 (gimple *def_stmt, enum vect_def_type dt)
>> {
>>
>> switch (dt)
>> {
>>case vect_internal_def || vect_external_def:
>> gcc_unreachable ()
>>
>>.. code for for all other cases..
>> }
>> }
>>
>> /* Used by existing code */
>> tree
>> vect_get_vec_def_for_operand (tree op, gimple *stmt, tree vectype)
>> {
>> vect_is_simple_use(op, loop_vinfo, &def_stmt, &dt); ..and the dump
>>code
>>
>>
>> If dt == internal_def || vect_external_def:
>> .. Check for BOOLEAN_TYPE ..
>> return vect_init_vector (stmt, op, vector_type, NULL);
>>
>> else
>> vect_get_vec_def_for_operand_1 (def_stmt, dt)
>> }
>>
>>
>> Does that look better?
>
>Yes!
>
>Thanks,
>Richard.
>
This version of the patch addresses the simple+invariant issues
(and patch [3/3] optimizes it).
Also includes a small change to handle when the vect pattern has introduced
new pattern match statements (in vectorizable_live_operation if
STMT_VINFO_RELATED_STMT is not null then use it instead of stmt).
gcc/
* tree-vect-loop.c (vect_analyze_loop_operations): Allow live stmts.
(vectorizable_reduction): Check for new relevant state.
(vectorizable_live_operation): vectorize live stmts using
BIT_FIELD_REF. Remove special case for gimple assigns stmts.
* tree-vect-stmts.c (is_simple_and_all_uses_invariant): New function.
(vect_stmt_relevant_p): Check for stmts which are only used live.
(process_use): Use of a stmt does not inherit it's live value.
(vect_mark_stmts_to_be_vectorized): Simplify relevance inheritance.
(vect_analyze_stmt): Check for new relevant state.
*tree-vectorizer.h (vect_relevant): New entry for a stmt which is used
outside the loop, but not inside it.
testsuite/
* gcc.dg/tree-ssa/pr64183.c: Ensure test does not vectorize.
* testsuite/gcc.dg/vect/no-scevccp-vect-iv-2.c: Remove xfail.
* gcc.dg/vect/vect-live-1.c: New test.
* gcc.dg/vect/vect-live-2.c: New test.
* gcc.dg/vect/vect-live-3.c: New test.
* gcc.dg/vect/vect-live-4.c: New test.
* gcc.dg/vect/vect-live-5.c: New test.
* gcc.dg/vect/vect-live-slp-1.c: New test.
* gcc.dg/vect/vect-live-slp-2.c: New test.
* gcc.dg/vect/vect-live-slp-3.c: New test.
Alan.
2of3live.patch
Description: Binary data
Re: [PATCH][2/3] Vectorize inductions that are live after the loop
On Thu, Jun 2, 2016 at 6:11 PM, Alan Hayward wrote:
>
>
> On 01/06/2016 10:51, "Richard Biener" wrote:
>
>>On Wed, Jun 1, 2016 at 10:46 AM, Alan Hayward
>>wrote:
>>>
>>>
>>> On 30/05/2016 14:22, "Richard Biener"
>>>wrote:
>>>
On Fri, May 27, 2016 at 5:12 PM, Alan Hayward
wrote:
>
> On 27/05/2016 12:41, "Richard Biener"
>wrote:
>
>>On Fri, May 27, 2016 at 11:09 AM, Alan Hayward
>>wrote:
>>>
>
>>
>>The rest of the changes look ok to me.
>
> Does that include PATCH 1/3 ?
I don't like how 1/3 ends up looking :/ So what was the alternative
again?
I looked into 1/3 and what it takes to remove the 'stmt' argument and
instead pass in a vect_def_type. It's a bit twisted and just adding
another
argument (the loop_vinfo) doesn't help things here.
So - instead of 1/3 you might want to split out a function
tree
vect_get_vec_def_for_operand_1 (gimple *def_stmt, enum vect_def_type
dt, tree vectype)
{
switch (dt)
{
...
}
}
and for constant/external force vectype != NULL.
>>>
>>> I’m still a little confused as to exactly what you want here.
>>>
>>> From your two comments I think you wanted me to completely remove the
>>> boolean type check and the vect_init_vector call. But if I remove that
>>> then other code paths will break.
>>>
>>> However, I’ve just realised that in vectorized_live_operation I already
>>> have the def stmt and I can easily get hold of dt from
>>>STMT_VINFO_DEF_TYPE.
>>> Which means I can call vect_get_vec_def_for_operand_1 from
>>> vectorized_live_operation.
>>>
>>> I’ve put together a version where I have:
>>>
>>> tree
>>> vect_get_vec_def_for_operand_1 (gimple *def_stmt, enum vect_def_type dt)
>>> {
>>>
>>> switch (dt)
>>> {
>>>case vect_internal_def || vect_external_def:
>>> gcc_unreachable ()
>>>
>>>.. code for for all other cases..
>>> }
>>> }
>>>
>>> /* Used by existing code */
>>> tree
>>> vect_get_vec_def_for_operand (tree op, gimple *stmt, tree vectype)
>>> {
>>> vect_is_simple_use(op, loop_vinfo, &def_stmt, &dt); ..and the dump
>>>code
>>>
>>>
>>> If dt == internal_def || vect_external_def:
>>> .. Check for BOOLEAN_TYPE ..
>>> return vect_init_vector (stmt, op, vector_type, NULL);
>>>
>>> else
>>> vect_get_vec_def_for_operand_1 (def_stmt, dt)
>>> }
>>>
>>>
>>> Does that look better?
>>
>>Yes!
>>
>>Thanks,
>>Richard.
>>
>
>
> This version of the patch addresses the simple+invariant issues
> (and patch [3/3] optimizes it).
>
> Also includes a small change to handle when the vect pattern has introduced
> new pattern match statements (in vectorizable_live_operation if
> STMT_VINFO_RELATED_STMT is not null then use it instead of stmt).
This is ok.
Thanks,
Richard.
> gcc/
> * tree-vect-loop.c (vect_analyze_loop_operations): Allow live stmts.
> (vectorizable_reduction): Check for new relevant state.
> (vectorizable_live_operation): vectorize live stmts using
> BIT_FIELD_REF. Remove special case for gimple assigns stmts.
> * tree-vect-stmts.c (is_simple_and_all_uses_invariant): New function.
> (vect_stmt_relevant_p): Check for stmts which are only used live.
> (process_use): Use of a stmt does not inherit it's live value.
> (vect_mark_stmts_to_be_vectorized): Simplify relevance inheritance.
> (vect_analyze_stmt): Check for new relevant state.
> *tree-vectorizer.h (vect_relevant): New entry for a stmt which is used
> outside the loop, but not inside it.
>
> testsuite/
> * gcc.dg/tree-ssa/pr64183.c: Ensure test does not vectorize.
> * testsuite/gcc.dg/vect/no-scevccp-vect-iv-2.c: Remove xfail.
> * gcc.dg/vect/vect-live-1.c: New test.
> * gcc.dg/vect/vect-live-2.c: New test.
> * gcc.dg/vect/vect-live-3.c: New test.
> * gcc.dg/vect/vect-live-4.c: New test.
> * gcc.dg/vect/vect-live-5.c: New test.
> * gcc.dg/vect/vect-live-slp-1.c: New test.
> * gcc.dg/vect/vect-live-slp-2.c: New test.
> * gcc.dg/vect/vect-live-slp-3.c: New test.
>
>
> Alan.
>
Re: [PATCH][2/3] Vectorize inductions that are live after the loop
On Thu, Jun 02, 2016 at 05:11:15PM +0100, Alan Hayward wrote:
> * gcc.dg/vect/vect-live-1.c: New test.
> * gcc.dg/vect/vect-live-2.c: New test.
> * gcc.dg/vect/vect-live-5.c: New test.
> * gcc.dg/vect/vect-live-slp-1.c: New test.
> * gcc.dg/vect/vect-live-slp-2.c: New test.
> * gcc.dg/vect/vect-live-slp-3.c: New test.
These tests all fail for me on i686-linux. The problem is
in the use of dg-options in gcc.dg/vect/, where it override all the various
needed vectorization options that need to be enabled on various arches
(e.g. -msse2 on i686).
Fixed thusly, tested on x86_64-linux and i686-linux, ok for trunk?
2016-06-03 Jakub Jelinek
* gcc.dg/vect/vect-live-1.c: Remove dg-options. Add
dg-additional-options with just -fno-tree-scev-cprop in it.
* gcc.dg/vect/vect-live-2.c: Likewise.
* gcc.dg/vect/vect-live-5.c: Likewise.
* gcc.dg/vect/vect-live-slp-1.c: Likewise.
* gcc.dg/vect/vect-live-slp-2.c: Likewise.
* gcc.dg/vect/vect-live-slp-3.c: Likewise.
--- gcc/testsuite/gcc.dg/vect/vect-live-1.c.jj 2016-06-03 17:36:38.0
+0200
+++ gcc/testsuite/gcc.dg/vect/vect-live-1.c 2016-06-03 19:37:09.176283421
+0200
@@ -1,5 +1,5 @@
/* { dg-require-effective-target vect_int } */
-/* { dg-options "-O2 -ftree-vectorize -fno-tree-scev-cprop
-fdump-tree-vect-details" } */
+/* { dg-additional-options "-fno-tree-scev-cprop" } */
#include "tree-vect.h"
--- gcc/testsuite/gcc.dg/vect/vect-live-2.c.jj 2016-06-03 17:36:38.0
+0200
+++ gcc/testsuite/gcc.dg/vect/vect-live-2.c 2016-06-03 19:37:27.537042349
+0200
@@ -1,5 +1,5 @@
/* { dg-require-effective-target vect_int } */
-/* { dg-options "-O2 -ftree-vectorize -fno-tree-scev-cprop
-fdump-tree-vect-details" } */
+/* { dg-additional-options "-fno-tree-scev-cprop" } */
#include "tree-vect.h"
--- gcc/testsuite/gcc.dg/vect/vect-live-5.c.jj 2016-06-03 17:36:38.0
+0200
+++ gcc/testsuite/gcc.dg/vect/vect-live-5.c 2016-06-03 19:37:53.239704879
+0200
@@ -1,5 +1,5 @@
/* { dg-require-effective-target vect_int } */
-/* { dg-options "-O2 -ftree-vectorize -fno-tree-scev-cprop
-fdump-tree-vect-details" } */
+/* { dg-additional-options "-fno-tree-scev-cprop" } */
#include "tree-vect.h"
--- gcc/testsuite/gcc.dg/vect/vect-live-slp-1.c.jj 2016-06-03
17:36:38.0 +0200
+++ gcc/testsuite/gcc.dg/vect/vect-live-slp-1.c 2016-06-03 19:38:13.341440948
+0200
@@ -1,5 +1,5 @@
/* { dg-require-effective-target vect_int } */
-/* { dg-options "-O2 -ftree-vectorize -fno-tree-scev-cprop
-fdump-tree-vect-details" } */
+/* { dg-options "-fno-tree-scev-cprop" } */
#include "tree-vect.h"
--- gcc/testsuite/gcc.dg/vect/vect-live-slp-2.c.jj 2016-06-03
17:36:38.0 +0200
+++ gcc/testsuite/gcc.dg/vect/vect-live-slp-2.c 2016-06-03 19:38:32.364191184
+0200
@@ -1,5 +1,5 @@
/* { dg-require-effective-target vect_int } */
-/* { dg-options "-O2 -ftree-vectorize -fno-tree-scev-cprop
-fdump-tree-vect-details" } */
+/* { dg-additional-options "-fno-tree-scev-cprop" } */
#include "tree-vect.h"
--- gcc/testsuite/gcc.dg/vect/vect-live-slp-3.c.jj 2016-06-03
17:36:38.0 +0200
+++ gcc/testsuite/gcc.dg/vect/vect-live-slp-3.c 2016-06-03 19:38:49.490966314
+0200
@@ -1,5 +1,5 @@
/* { dg-require-effective-target vect_int } */
-/* { dg-options "-O2 -ftree-vectorize -fno-tree-scev-cprop
-fdump-tree-vect-details" } */
+/* { dg-options "-fno-tree-scev-cprop" } */
#include "tree-vect.h"
Jakub
Re: [PATCH][2/3] Vectorize inductions that are live after the loop
On June 3, 2016 7:45:24 PM GMT+02:00, Jakub Jelinek wrote:
>On Thu, Jun 02, 2016 at 05:11:15PM +0100, Alan Hayward wrote:
>> * gcc.dg/vect/vect-live-1.c: New test.
>> * gcc.dg/vect/vect-live-2.c: New test.
>> * gcc.dg/vect/vect-live-5.c: New test.
>> * gcc.dg/vect/vect-live-slp-1.c: New test.
>> * gcc.dg/vect/vect-live-slp-2.c: New test.
>> * gcc.dg/vect/vect-live-slp-3.c: New test.
>
>These tests all fail for me on i686-linux. The problem is
>in the use of dg-options in gcc.dg/vect/, where it override all the
>various
>needed vectorization options that need to be enabled on various arches
>(e.g. -msse2 on i686).
>
>Fixed thusly, tested on x86_64-linux and i686-linux, ok for trunk?
OK.
Richard.
>
>2016-06-03 Jakub Jelinek
>
> * gcc.dg/vect/vect-live-1.c: Remove dg-options. Add
> dg-additional-options with just -fno-tree-scev-cprop in it.
> * gcc.dg/vect/vect-live-2.c: Likewise.
> * gcc.dg/vect/vect-live-5.c: Likewise.
> * gcc.dg/vect/vect-live-slp-1.c: Likewise.
> * gcc.dg/vect/vect-live-slp-2.c: Likewise.
> * gcc.dg/vect/vect-live-slp-3.c: Likewise.
>
>--- gcc/testsuite/gcc.dg/vect/vect-live-1.c.jj 2016-06-03
>17:36:38.0 +0200
>+++ gcc/testsuite/gcc.dg/vect/vect-live-1.c2016-06-03
>19:37:09.176283421 +0200
>@@ -1,5 +1,5 @@
> /* { dg-require-effective-target vect_int } */
>-/* { dg-options "-O2 -ftree-vectorize -fno-tree-scev-cprop
>-fdump-tree-vect-details" } */
>+/* { dg-additional-options "-fno-tree-scev-cprop" } */
>
> #include "tree-vect.h"
>
>--- gcc/testsuite/gcc.dg/vect/vect-live-2.c.jj 2016-06-03
>17:36:38.0 +0200
>+++ gcc/testsuite/gcc.dg/vect/vect-live-2.c2016-06-03
>19:37:27.537042349 +0200
>@@ -1,5 +1,5 @@
> /* { dg-require-effective-target vect_int } */
>-/* { dg-options "-O2 -ftree-vectorize -fno-tree-scev-cprop
>-fdump-tree-vect-details" } */
>+/* { dg-additional-options "-fno-tree-scev-cprop" } */
>
> #include "tree-vect.h"
>
>--- gcc/testsuite/gcc.dg/vect/vect-live-5.c.jj 2016-06-03
>17:36:38.0 +0200
>+++ gcc/testsuite/gcc.dg/vect/vect-live-5.c2016-06-03
>19:37:53.239704879 +0200
>@@ -1,5 +1,5 @@
> /* { dg-require-effective-target vect_int } */
>-/* { dg-options "-O2 -ftree-vectorize -fno-tree-scev-cprop
>-fdump-tree-vect-details" } */
>+/* { dg-additional-options "-fno-tree-scev-cprop" } */
>
> #include "tree-vect.h"
>
>--- gcc/testsuite/gcc.dg/vect/vect-live-slp-1.c.jj 2016-06-03
>17:36:38.0 +0200
>+++ gcc/testsuite/gcc.dg/vect/vect-live-slp-1.c2016-06-03
>19:38:13.341440948 +0200
>@@ -1,5 +1,5 @@
> /* { dg-require-effective-target vect_int } */
>-/* { dg-options "-O2 -ftree-vectorize -fno-tree-scev-cprop
>-fdump-tree-vect-details" } */
>+/* { dg-options "-fno-tree-scev-cprop" } */
>
> #include "tree-vect.h"
>
>--- gcc/testsuite/gcc.dg/vect/vect-live-slp-2.c.jj 2016-06-03
>17:36:38.0 +0200
>+++ gcc/testsuite/gcc.dg/vect/vect-live-slp-2.c2016-06-03
>19:38:32.364191184 +0200
>@@ -1,5 +1,5 @@
> /* { dg-require-effective-target vect_int } */
>-/* { dg-options "-O2 -ftree-vectorize -fno-tree-scev-cprop
>-fdump-tree-vect-details" } */
>+/* { dg-additional-options "-fno-tree-scev-cprop" } */
>
> #include "tree-vect.h"
>
>--- gcc/testsuite/gcc.dg/vect/vect-live-slp-3.c.jj 2016-06-03
>17:36:38.0 +0200
>+++ gcc/testsuite/gcc.dg/vect/vect-live-slp-3.c2016-06-03
>19:38:49.490966314 +0200
>@@ -1,5 +1,5 @@
> /* { dg-require-effective-target vect_int } */
>-/* { dg-options "-O2 -ftree-vectorize -fno-tree-scev-cprop
>-fdump-tree-vect-details" } */
>+/* { dg-options "-fno-tree-scev-cprop" } */
>
> #include "tree-vect.h"
>
>
>
> Jakub
Re: [PATCH][2/3] Vectorize inductions that are live after the loop
Alan Hayward writes: > * gcc.dg/vect/vect-live-2.c: New test. This test fails on powerpc64 (with -m64, but not with -m32): $ grep 'vectorized.*loops' ./vect-live-2.c.149t.vect ../gcc/testsuite/gcc.dg/vect/vect-live-2.c:10:1: note: vectorized 0 loops in function. ../gcc/testsuite/gcc.dg/vect/vect-live-2.c:29:1: note: vectorized 0 loops in function. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH][2/3] Vectorize inductions that are live after the loop
On 03/06/2016 18:45, "Jakub Jelinek" wrote:
>On Thu, Jun 02, 2016 at 05:11:15PM +0100, Alan Hayward wrote:
>> * gcc.dg/vect/vect-live-1.c: New test.
>> * gcc.dg/vect/vect-live-2.c: New test.
>> * gcc.dg/vect/vect-live-5.c: New test.
>> * gcc.dg/vect/vect-live-slp-1.c: New test.
>> * gcc.dg/vect/vect-live-slp-2.c: New test.
>> * gcc.dg/vect/vect-live-slp-3.c: New test.
>
>These tests all fail for me on i686-linux. The problem is
>in the use of dg-options in gcc.dg/vect/, where it override all the
>various
>needed vectorization options that need to be enabled on various arches
>(e.g. -msse2 on i686).
>
>Fixed thusly, tested on x86_64-linux and i686-linux, ok for trunk?
Thanks for fixing this. However, I think you had a copy/paste error.
For vect-live-slp-1.c and vect-live-slp-3.c you used dg-options instead
of dg-additional-options, which causes the tests to fail for me as
UNRESOLVED.
Ok to commit?
Alan.
testsuite/
* gcc.dg/vect/vect-live-1.c: Use additional-options.
* gcc.dg/vect/vect-live-3.c: Likewise.
diff --git a/gcc/testsuite/gcc.dg/vect/vect-live-slp-1.c
b/gcc/testsuite/gcc.dg/vect/vect-live-slp-1.c
index
82cd8dcabed8f18408e0e5cf295c2f15e0621ae6..7fefbff17d8c34bdfb1e8d697d2b9a70a
048ae16 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-live-slp-1.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-live-slp-1.c
@@ -1,5 +1,5 @@
/* { dg-require-effective-target vect_int } */
-/* { dg-options "-fno-tree-scev-cprop" } */
+/* { dg-additional-options "-fno-tree-scev-cprop" } */
#include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/vect-live-slp-3.c
b/gcc/testsuite/gcc.dg/vect/vect-live-slp-3.c
index
9e4a59eca593289050086b4b0a1347be5d748723..aacf5cb98071f6fec1f4b522eeefeb669
6787334 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-live-slp-3.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-live-slp-3.c
@@ -1,5 +1,5 @@
/* { dg-require-effective-target vect_int } */
-/* { dg-options "-fno-tree-scev-cprop" } */
+/* { dg-additional-options "-fno-tree-scev-cprop" } */
#include "tree-vect.h"
Re: [PATCH][2/3] Vectorize inductions that are live after the loop
On Mon, Jun 06, 2016 at 10:03:12AM +0100, Alan Hayward wrote: > > On 03/06/2016 18:45, "Jakub Jelinek" wrote: > > >On Thu, Jun 02, 2016 at 05:11:15PM +0100, Alan Hayward wrote: > >>* gcc.dg/vect/vect-live-1.c: New test. > >>* gcc.dg/vect/vect-live-2.c: New test. > >>* gcc.dg/vect/vect-live-5.c: New test. > >>* gcc.dg/vect/vect-live-slp-1.c: New test. > >>* gcc.dg/vect/vect-live-slp-2.c: New test. > >>* gcc.dg/vect/vect-live-slp-3.c: New test. > > > >These tests all fail for me on i686-linux. The problem is > >in the use of dg-options in gcc.dg/vect/, where it override all the > >various > >needed vectorization options that need to be enabled on various arches > >(e.g. -msse2 on i686). > > > >Fixed thusly, tested on x86_64-linux and i686-linux, ok for trunk? > > Thanks for fixing this. However, I think you had a copy/paste error. > For vect-live-slp-1.c and vect-live-slp-3.c you used dg-options instead > of dg-additional-options, which causes the tests to fail for me as > UNRESOLVED. > > Ok to commit? Oops. Sure, thanks. > testsuite/ > * gcc.dg/vect/vect-live-1.c: Use additional-options. > * gcc.dg/vect/vect-live-3.c: Likewise. Jakub
Re: [PATCH][2/3] Vectorize inductions that are live after the loop
On 05/06/2016 12:00, "Andreas Schwab" wrote: >Alan Hayward writes: > >> * gcc.dg/vect/vect-live-2.c: New test. > >This test fails on powerpc64 (with -m64, but not with -m32): > >$ grep 'vectorized.*loops' ./vect-live-2.c.149t.vect >../gcc/testsuite/gcc.dg/vect/vect-live-2.c:10:1: note: vectorized 0 loops >in function. >../gcc/testsuite/gcc.dg/vect/vect-live-2.c:29:1: note: vectorized 0 loops >in function. > > "note: not vectorized: relevant stmt not supported: _1 = (long unsigned int) j_24;" This is failing because power does not support vectorising a cast from int to long. (It works on power 32bit because longs are 32bit and therefore no need to cast). Can someone please suggest a target-supports define (or another method) I can use to disable this test for power 64bit (but not 32bit) ? I tried using vect_multiple_sizes, but that will also disable the test on x86 without avx. Thanks, Alan.
Re: [PATCH][2/3] Vectorize inductions that are live after the loop
Alan Hayward writes: > On 05/06/2016 12:00, "Andreas Schwab" wrote: > >>Alan Hayward writes: >> >>> * gcc.dg/vect/vect-live-2.c: New test. >> >>This test fails on powerpc64 (with -m64, but not with -m32): >> >>$ grep 'vectorized.*loops' ./vect-live-2.c.149t.vect >>../gcc/testsuite/gcc.dg/vect/vect-live-2.c:10:1: note: vectorized 0 loops >>in function. >>../gcc/testsuite/gcc.dg/vect/vect-live-2.c:29:1: note: vectorized 0 loops >>in function. >> >> > > "note: not vectorized: relevant stmt not supported: _1 = (long unsigned > int) j_24;" > > > This is failing because power does not support vectorising a cast from int > to long. > (It works on power 32bit because longs are 32bit and therefore no need to > cast). > > Can someone please suggest a target-supports define (or another method) I > can use to > disable this test for power 64bit (but not 32bit) ? > I tried using vect_multiple_sizes, but that will also disable the test on > x86 without > avx. I'm also seeing new FAILs on Solaris/SPARC: +FAIL: gcc.dg/vect/vect-live-2.c -flto -ffat-lto-objects scan-tree-dump-times v ect "vectorized 1 loops" 1 +FAIL: gcc.dg/vect/vect-live-2.c scan-tree-dump-times vect "vectorized 1 loops" 1 32- and 64-bit: vect-live-2.c:16:3: note: not vectorized: relevant stmt not supported: _2 = j.0_1 * 4; vect-live-2.c:48:7: note: not vectorized: control flow in loop. vect-live-2.c:35:3: note: not vectorized: loop contains function calls or data references that cannot be analyzed and +FAIL: gcc.dg/vect/vect-live-slp-3.c -flto -ffat-lto-objects scan-tree-dump-times vect "vec_stmt_relevant_p: stmt live but not relevant" 4 +FAIL: gcc.dg/vect/vect-live-slp-3.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 4 +FAIL: gcc.dg/vect/vect-live-slp-3.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorizing stmts using SLP" 4 +FAIL: gcc.dg/vect/vect-live-slp-3.c scan-tree-dump-times vect "vec_stmt_relevant_p: stmt live but not relevant" 4 +FAIL: gcc.dg/vect/vect-live-slp-3.c scan-tree-dump-times vect "vectorized 1 loops" 4 +FAIL: gcc.dg/vect/vect-live-slp-3.c scan-tree-dump-times vect "vectorizing stmts using SLP" 4 vect-live-slp-3.c:29:1: note: not vectorized: no vectype for stmt: n0_29 = *_4; vect-live-slp-3.c:30:1: note: not vectorized: no vectype for stmt: n0_29 = *_4; vect-live-slp-3.c:31:1: note: not vectorized: no vectype for stmt: n0_29 = *_4; vect-live-slp-3.c:32:1: note: not vectorized: no vectype for stmt: n0_29 = *_4; vect-live-slp-3.c:62:4: note: not vectorized: control flow in loop. vect-live-slp-3.c:45:3: note: not vectorized: loop contains function calls or data references that cannot be analyzed Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH][2/3] Vectorize inductions that are live after the loop
On 07/06/2016 10:28, "Rainer Orth" wrote:
>Alan Hayward writes:
>
>> On 05/06/2016 12:00, "Andreas Schwab" wrote:
>>
>>>Alan Hayward writes:
>>>
* gcc.dg/vect/vect-live-2.c: New test.
>>>
>>>This test fails on powerpc64 (with -m64, but not with -m32):
>>>
>>>$ grep 'vectorized.*loops' ./vect-live-2.c.149t.vect
>>>../gcc/testsuite/gcc.dg/vect/vect-live-2.c:10:1: note: vectorized 0
>>>loops
>>>in function.
>>>../gcc/testsuite/gcc.dg/vect/vect-live-2.c:29:1: note: vectorized 0
>>>loops
>>>in function.
>>>
>>>
>>
>> "note: not vectorized: relevant stmt not supported: _1 = (long unsigned
>> int) j_24;"
>>
>>
>> This is failing because power does not support vectorising a cast from
>>int
>> to long.
>> (It works on power 32bit because longs are 32bit and therefore no need
>>to
>> cast).
>>
>> Can someone please suggest a target-supports define (or another method)
>>I
>> can use to
>> disable this test for power 64bit (but not 32bit) ?
>> I tried using vect_multiple_sizes, but that will also disable the test
>>on
>> x86 without
>> avx.
>
>I'm also seeing new FAILs on Solaris/SPARC:
>
>+FAIL: gcc.dg/vect/vect-live-2.c -flto -ffat-lto-objects
>scan-tree-dump-times v
>ect "vectorized 1 loops" 1
>+FAIL: gcc.dg/vect/vect-live-2.c scan-tree-dump-times vect "vectorized 1
>loops"
>1
>
>32- and 64-bit:
>
>vect-live-2.c:16:3: note: not vectorized: relevant stmt not supported: _2
>= j.0_1 * 4;
>vect-live-2.c:48:7: note: not vectorized: control flow in loop.
>vect-live-2.c:35:3: note: not vectorized: loop contains function calls or
>data references that cannot be analyzed
>
>and
>
>+FAIL: gcc.dg/vect/vect-live-slp-3.c -flto -ffat-lto-objects
>scan-tree-dump-times vect "vec_stmt_relevant_p: stmt live but not
>relevant" 4
>+FAIL: gcc.dg/vect/vect-live-slp-3.c -flto -ffat-lto-objects
>scan-tree-dump-times vect "vectorized 1 loops" 4
>+FAIL: gcc.dg/vect/vect-live-slp-3.c -flto -ffat-lto-objects
>scan-tree-dump-times vect "vectorizing stmts using SLP" 4
>+FAIL: gcc.dg/vect/vect-live-slp-3.c scan-tree-dump-times vect
>"vec_stmt_relevant_p: stmt live but not relevant" 4
>+FAIL: gcc.dg/vect/vect-live-slp-3.c scan-tree-dump-times vect
>"vectorized 1 loops" 4
>+FAIL: gcc.dg/vect/vect-live-slp-3.c scan-tree-dump-times vect
>"vectorizing stmts using SLP" 4
>
>vect-live-slp-3.c:29:1: note: not vectorized: no vectype for stmt: n0_29
>= *_4;
>vect-live-slp-3.c:30:1: note: not vectorized: no vectype for stmt: n0_29
>= *_4;
>vect-live-slp-3.c:31:1: note: not vectorized: no vectype for stmt: n0_29
>= *_4;
>vect-live-slp-3.c:32:1: note: not vectorized: no vectype for stmt: n0_29
>= *_4;
>vect-live-slp-3.c:62:4: note: not vectorized: control flow in loop.
>vect-live-slp-3.c:45:3: note: not vectorized: loop contains function
>calls or data references that cannot be analyzed
>
I’ve been trying both these tests on x86,aarch64,power,sparc
vect-live-slp-3.c
Fails on power 64 (altivec & vsx), sparc 64 (vis 2 & 3)
- due to long int unsupported
Pass on x86, aarch64, power 32 (altivec & vsx), sparc 32 (vis 2 & 3)
vect-live-2.c
Fails on power 64 (altivec & vsx), sparc 64 (vis 2 & 3)
- due to long int unsupported
Fails on sparc 32 (vis 2)
- due to multiply/shift not supported
Pass on x86, aarch64, power 32 (altivec & vsx), sparc 32 (vis 3)
Therefore I think both tests should be gated on “vect_long”.
In addition, vect-live-2.c should also be gated on “vect_shift”
“vect_long” is not currently enabled for aarch64, but should be.
Also “vect_shift” is not currently enabled for sparc 32 (vis 3), but
probably
should be. I leave this for a task for a sparc maintainer to add (as I’m
unable to test).
This patch fixes the targets for vect-live-slp-3.c and vect-live-2.c.
It also adds aarch64 to vect_long.
As a side consequence, the following vector tests are now enabled for
aarch64:
pr18425.c, pr30843.c, pr36493.c, pr42193.c and pr60656.c
Tested on aarch64 and x86.
Tested by inspection on power and sparc
Ok to commit?
testsuite/
* gcc.dg/vect/vect-live-2.c : Likewise
* gcc.dg/vect/vect-live-slp-3.c : Update effective target
* lib/target-supports.exp : Add aarch64 to vect_long
diff --git a/gcc/testsuite/gcc.dg/vect/vect-live-2.c
b/gcc/testsuite/gcc.dg/vect/vect-live-2.c
index
53adc3fee006e0577a4cf2f9ba8fe091d2a09353..9460624a515945bdd72f98a0b1a6751fd
c7a75de 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-live-2.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-live-2.c
@@ -1,4 +1,5 @@
-/* { dg-require-effective-target vect_int } */
+/* { dg-require-effective-target vect_long } */
+/* { dg-require-effective-target vect_shift } */
/* { dg-additional-options "-fno-tree-scev-cprop" } */
#include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/vect-live-slp-3.c
b/gcc/testsuite/gcc.dg/vect/vect-live-slp-3.c
index
aacf5cb98071f6fec1f4b522eeefeb6696787334..70947afcc45d30987fc6df2db634d002d
33b360f 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-live-slp-3.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-live-slp-3.c
@@ -1,4 +1,
Re: [PATCH][2/3] Vectorize inductions that are live after the loop
On Tue, 7 Jun 2016, Alan Hayward wrote: > testsuite/ > * gcc.dg/vect/vect-live-2.c : Likewise > * gcc.dg/vect/vect-live-slp-3.c : Update effective target > * lib/target-supports.exp : Add aarch64 to vect_long "Likewise" entries usually follow those they refer to (i.e., while ChangeLog files are "latest first", any individual entry is read "top-down"). And no space after the filename, and a full stop at the end of each entry starting with a "*". Gerald
Re: [PATCH][2/3] Vectorize inductions that are live after the loop
On Tue, Jun 7, 2016 at 4:32 PM, Alan Hayward wrote:
>
>
> On 07/06/2016 10:28, "Rainer Orth" wrote:
>
>>Alan Hayward writes:
>>
>>> On 05/06/2016 12:00, "Andreas Schwab" wrote:
>>>
Alan Hayward writes:
>* gcc.dg/vect/vect-live-2.c: New test.
This test fails on powerpc64 (with -m64, but not with -m32):
$ grep 'vectorized.*loops' ./vect-live-2.c.149t.vect
../gcc/testsuite/gcc.dg/vect/vect-live-2.c:10:1: note: vectorized 0
loops
in function.
../gcc/testsuite/gcc.dg/vect/vect-live-2.c:29:1: note: vectorized 0
loops
in function.
>>>
>>> "note: not vectorized: relevant stmt not supported: _1 = (long unsigned
>>> int) j_24;"
>>>
>>>
>>> This is failing because power does not support vectorising a cast from
>>>int
>>> to long.
>>> (It works on power 32bit because longs are 32bit and therefore no need
>>>to
>>> cast).
>>>
>>> Can someone please suggest a target-supports define (or another method)
>>>I
>>> can use to
>>> disable this test for power 64bit (but not 32bit) ?
>>> I tried using vect_multiple_sizes, but that will also disable the test
>>>on
>>> x86 without
>>> avx.
>>
>>I'm also seeing new FAILs on Solaris/SPARC:
>>
>>+FAIL: gcc.dg/vect/vect-live-2.c -flto -ffat-lto-objects
>>scan-tree-dump-times v
>>ect "vectorized 1 loops" 1
>>+FAIL: gcc.dg/vect/vect-live-2.c scan-tree-dump-times vect "vectorized 1
>>loops"
>>1
>>
>>32- and 64-bit:
>>
>>vect-live-2.c:16:3: note: not vectorized: relevant stmt not supported: _2
>>= j.0_1 * 4;
>>vect-live-2.c:48:7: note: not vectorized: control flow in loop.
>>vect-live-2.c:35:3: note: not vectorized: loop contains function calls or
>>data references that cannot be analyzed
>>
>>and
>>
>>+FAIL: gcc.dg/vect/vect-live-slp-3.c -flto -ffat-lto-objects
>>scan-tree-dump-times vect "vec_stmt_relevant_p: stmt live but not
>>relevant" 4
>>+FAIL: gcc.dg/vect/vect-live-slp-3.c -flto -ffat-lto-objects
>>scan-tree-dump-times vect "vectorized 1 loops" 4
>>+FAIL: gcc.dg/vect/vect-live-slp-3.c -flto -ffat-lto-objects
>>scan-tree-dump-times vect "vectorizing stmts using SLP" 4
>>+FAIL: gcc.dg/vect/vect-live-slp-3.c scan-tree-dump-times vect
>>"vec_stmt_relevant_p: stmt live but not relevant" 4
>>+FAIL: gcc.dg/vect/vect-live-slp-3.c scan-tree-dump-times vect
>>"vectorized 1 loops" 4
>>+FAIL: gcc.dg/vect/vect-live-slp-3.c scan-tree-dump-times vect
>>"vectorizing stmts using SLP" 4
>>
>>vect-live-slp-3.c:29:1: note: not vectorized: no vectype for stmt: n0_29
>>= *_4;
>>vect-live-slp-3.c:30:1: note: not vectorized: no vectype for stmt: n0_29
>>= *_4;
>>vect-live-slp-3.c:31:1: note: not vectorized: no vectype for stmt: n0_29
>>= *_4;
>>vect-live-slp-3.c:32:1: note: not vectorized: no vectype for stmt: n0_29
>>= *_4;
>>vect-live-slp-3.c:62:4: note: not vectorized: control flow in loop.
>>vect-live-slp-3.c:45:3: note: not vectorized: loop contains function
>>calls or data references that cannot be analyzed
>>
>
>
> I’ve been trying both these tests on x86,aarch64,power,sparc
>
> vect-live-slp-3.c
> Fails on power 64 (altivec & vsx), sparc 64 (vis 2 & 3)
> - due to long int unsupported
> Pass on x86, aarch64, power 32 (altivec & vsx), sparc 32 (vis 2 & 3)
>
> vect-live-2.c
> Fails on power 64 (altivec & vsx), sparc 64 (vis 2 & 3)
> - due to long int unsupported
> Fails on sparc 32 (vis 2)
> - due to multiply/shift not supported
> Pass on x86, aarch64, power 32 (altivec & vsx), sparc 32 (vis 3)
>
>
> Therefore I think both tests should be gated on “vect_long”.
> In addition, vect-live-2.c should also be gated on “vect_shift”
>
> “vect_long” is not currently enabled for aarch64, but should be.
>
> Also “vect_shift” is not currently enabled for sparc 32 (vis 3), but
> probably
> should be. I leave this for a task for a sparc maintainer to add (as I’m
> unable to test).
>
>
>
>
> This patch fixes the targets for vect-live-slp-3.c and vect-live-2.c.
> It also adds aarch64 to vect_long.
>
> As a side consequence, the following vector tests are now enabled for
> aarch64:
> pr18425.c, pr30843.c, pr36493.c, pr42193.c and pr60656.c
>
> Tested on aarch64 and x86.
> Tested by inspection on power and sparc
>
> Ok to commit?
Ok.
Thanks,
Richard.
> testsuite/
> * gcc.dg/vect/vect-live-2.c : Likewise
> * gcc.dg/vect/vect-live-slp-3.c : Update effective target
> * lib/target-supports.exp : Add aarch64 to vect_long
>
>
>
>
> diff --git a/gcc/testsuite/gcc.dg/vect/vect-live-2.c
> b/gcc/testsuite/gcc.dg/vect/vect-live-2.c
> index
> 53adc3fee006e0577a4cf2f9ba8fe091d2a09353..9460624a515945bdd72f98a0b1a6751fd
> c7a75de 100644
> --- a/gcc/testsuite/gcc.dg/vect/vect-live-2.c
> +++ b/gcc/testsuite/gcc.dg/vect/vect-live-2.c
> @@ -1,4 +1,5 @@
> -/* { dg-require-effective-target vect_int } */
> +/* { dg-require-effective-target vect_long } */
> +/* { dg-require-effective-target vect_shift } */
> /* { dg-additional-options "-fno-tree-scev-cprop" } */
>
> #include "tree-vect.h"
> diff --git a/gcc/testsuite/gcc.dg/vect/v
