On Wed, Jan 13, 2016 at 06:53:06PM +, Joseph Myers wrote:
> Will -Wsign-compare warnings be generated for the implicit signed /
> unsigned conversions in comparisons, as for scalar comparisons?
Good point. No, with the previous patch -Wsign-compare would be quiet. But
since it probably shou
On January 13, 2016 4:26:50 PM GMT+01:00, Marek Polacek
wrote:
>We crash on the following testcase because the FEs create
>
> VEC_COND_EXPR < a == b , { -1, -1, -1, -1 } , { 0, 0, 0, 0 } >
>
>where the operands of the comparison are same exce
Will -Wsign-compare warnings be generated for the implicit signed /
unsigned conversions in comparisons, as for scalar comparisons?
--
Joseph S. Myers
jos...@codesourcery.com
We crash on the following testcase because the FEs create
VEC_COND_EXPR < a == b , { -1, -1, -1, -1 } , { 0, 0, 0, 0 } >
where the operands of the comparison are same except for the sign (it's
vector_types_compatible_elements_p that says that). But GIMPLE doesn't
like the d
2015-11-12 13:03 GMT+03:00 Ramana Radhakrishnan :
> On Thu, Oct 8, 2015 at 4:50 PM, Ilya Enkovich wrote:
>> Hi,
>>
>> This patch allows COND_EXPR with no embedded comparison to be vectorized.
>> It's applied on top of vectorized comparison support series. New optab
>> vcond_mask_optab
>> is int
-
> gcc/
>
> 2015-10-08 Ilya Enkovich
>
> * optabs-query.h (get_vcond_mask_icode): New.
> * optabs-tree.c (expand_vec_cond_expr_p): Use
> get_vcond_mask_icode for VEC_COND_EXPR with mask.
> * optabs.c (expand_vec_cond_mask_expr): New.
> (expand
.
Ok.
Richard.
>
> 2015-10-26 Alan Hayward
>
> gcc/
> PR tree-optimization/65947
> * tree-vect-loop.c (vect_create_epilog_for_reduction):
> Fix VEC_COND_EXPR types.
>
>
> Cheers,
> Alan.
>
>
>
-vect-loop.c (vect_create_epilog_for_reduction):
Fix VEC_COND_EXPR types.
Cheers,
Alan.
fix_veccondexprtypes.patch
Description: Binary data
* optabs-tree.c (expand_vec_cond_expr_p): Use
> get_vcond_mask_icode for VEC_COND_EXPR with mask.
> * optabs.c (expand_vec_cond_mask_expr): New.
> (expand_vec_cond_expr): Use get_vcond_mask_icode
> when possible.
> * optabs.def (vcond_mask_optab): New.
On 10/02/2015 08:07 AM, Ilya Enkovich wrote:
Hi,
This patch forces boolean vector usage in VEC_COND_EXPR generated by
vectorizer. VEC_COND_EXPR expand is fixed appropriately.
Thanks,
Ilya
--
gcc/
2015-10-02 Ilya Enkovich
* optabs.c (expand_vec_cond_expr): Accept boolean vector
ed by target.
Thanks,
Ilya
--
gcc/
2015-10-08 Ilya Enkovich
* optabs-query.h (get_vcond_mask_icode): New.
* optabs-tree.c (expand_vec_cond_expr_p): Use
get_vcond_mask_icode for VEC_COND_EXPR with mask.
* optabs.c (expand_vec_cond_mask_expr)
Hi,
This patch forces boolean vector usage in VEC_COND_EXPR generated by
vectorizer. VEC_COND_EXPR expand is fixed appropriately.
Thanks,
Ilya
--
gcc/
2015-10-02 Ilya Enkovich
* optabs.c (expand_vec_cond_expr): Accept boolean vector as
condition operand.
* tree
Hi,
This patch adds scalar masks support for MASK_LOAD, MASK_STORE and
VEC_COND_EXPR. Each one gets new optab for scalar mask case and optab is
chosen depending on operands type. For VEC_COND_EXPR it's actually unclear
which mask to check in case comparison is used as the first op
On Sun, Mar 31, 2013 at 7:20 PM, Marc Glisse wrote:
> On Sun, 31 Mar 2013, Andrew Pinski wrote:
>
>> On Sun, Mar 31, 2013 at 6:31 AM, Marc Glisse wrote:
>>>
>>> Hello,
>>>
>>> this adds constant folding of VEC_COND_EXPR at the tree level by
>&
On Sun, 31 Mar 2013, Andrew Pinski wrote:
On Sun, Mar 31, 2013 at 6:31 AM, Marc Glisse wrote:
Hello,
this adds constant folding of VEC_COND_EXPR at the tree level by forwarding
to the VEC_PERM_EXPR code (a merge is a special case of a permutation). The
CONSTRUCTOR case may be unreachable for
On Sun, Mar 31, 2013 at 6:31 AM, Marc Glisse wrote:
> Hello,
>
> this adds constant folding of VEC_COND_EXPR at the tree level by forwarding
> to the VEC_PERM_EXPR code (a merge is a special case of a permutation). The
> CONSTRUCTOR case may be unreachable for now (it will probabl
Hello,
this adds constant folding of VEC_COND_EXPR at the tree level by
forwarding to the VEC_PERM_EXPR code (a merge is a special case of a
permutation). The CONSTRUCTOR case may be unreachable for now (it will
probably need an extra piece of code in tree-ssa-forwprop.c), but it seems
d_cond_expr_with_comparison): Use build_zero_cst.
> VEC_COND_EXPR cannot be lvalues.
> (fold_ternary_loc) : Merge with the COND_EXPR case.
>
>
> gcc/cp/
> * call.c (build_conditional_expr_1): Fold VEC_COND_EXPR.
>
> gcc/testsuite/
> * g++.dg/ext/vector21.
): New macro.
(VECTOR_INTEGER_TYPE_P, VECTOR_FLOAT_TYPE_P, FLOAT_TYPE_P,
TYPE_MODE): Use it.
* fold-const.c (fold_cond_expr_with_comparison): Use build_zero_cst.
VEC_COND_EXPR cannot be lvalues.
(fold_ternary_loc) : Merge with the COND_EXPR case.
gcc/cp
he VEC_COND_EXPRs can never be used as an lvalue in
>>>> the C++ frontend?
>>>
>>>
>>> Yes, as I mention in the ChangeLog. Not just the C++ front-end, it never
>>> makes sense to use a VEC_COND_EXPR as an lvalue, it really is just a
>>> terna
never
makes sense to use a VEC_COND_EXPR as an lvalue, it really is just a ternary
variant of BIT_AND_EXPR.
Then please add a && TREE_CODE == COND_EXPR around the
code handling only COND_EXPRs instead.
Hmm, there isn't one. There is just a block of code that is disabled when
th
On Mon, Mar 18, 2013 at 11:27 AM, Marc Glisse wrote:
> On Mon, 18 Mar 2013, Richard Biener wrote:
>
>>> 2013-03-17 Marc Glisse
>>>
>>> gcc/
>>> * fold-const.c (fold_cond_expr_with_comparison): Use
>>> build_ze
On Mon, 18 Mar 2013, Richard Biener wrote:
2013-03-17 Marc Glisse
gcc/
* fold-const.c (fold_cond_expr_with_comparison): Use build_zero_cst.
VEC_COND_EXPR cannot be lvalues.
(fold_ternary_loc) : Call
fold_cond_expr_with_comparison.
gcc/cp/
* call.c
On Sun, Mar 17, 2013 at 4:46 PM, Marc Glisse wrote:
> Hello,
>
> this patch adds a bit of folding to VEC_COND_EXPR so it is possible to
> generate ABS_EXPR and MAX_EXPR for vectors without relying on the
> vectorizer. I would have preferred to merge the COND_EXPR and VEC_COND_EX
Hello,
this patch adds a bit of folding to VEC_COND_EXPR so it is possible to
generate ABS_EXPR and MAX_EXPR for vectors without relying on the
vectorizer. I would have preferred to merge the COND_EXPR and
VEC_COND_EXPR cases, but there are too many things that need fixing first,
so I just
(fold_ternary_loc): Fold VEC_COND_EXPR if arg0 is
> either integer_all_onesp or integer_zerop.
> * tree-vect-stmts.c (vectorizable_condition): Build the condition
> using corresponding vector integer type instead of vectype.
>
> * gcc.dg/vect/fast-math-pr55281.
Hi!
This patch fixes two ICEs on the testcases, one is ICE in
expand_vector_condition which wouldn't handle VECTOR_CST as first argument
of VEC_COND_EXPR (plus a change to make sure it is folded earlier if
possible), and the vectorizable_condition change makes sure the condition
is actually
On 2012-11-02 02:44, Marc Glisse wrote:
> 2012-11-01 Marc Glisse
>
> PR middle-end/55001
>
> gcc/
> tree-vect-generic.c (expand_vector_condition): New function.
> (expand_vector_operations_1): Call it.
>
> testsuite/
> g++.dg/ext/vector19.C: Remove target restrictions.
> g
Hello,
this patch adds support for VEC_COND_EXPR to tree-vect-generic.c. It
doesn't try to use vectors of smaller size and jumps straight to
elementwise operations, so there is margin for improvements, but it seemed
better to have something asap that at least compiles.
For the test
On Fri, Oct 12, 2012 at 12:48 AM, Marc Glisse wrote:
> Hello,
>
> this patch brings VEC_COND_EXPR closer to what the doc now says. The
> non-comparison case and gimplification are dead paths currently, but it
> seems convenient to introduce them now. Note that by using the ge
Hello,
this patch brings VEC_COND_EXPR closer to what the doc now says. The
non-comparison case and gimplification are dead paths currently, but it
seems convenient to introduce them now. Note that by using the generic
ternary gimplification code, it will produce VEC_COND_EXPR with an
On Thu, Oct 11, 2012 at 1:20 AM, Marc Glisse wrote:
> On Mon, 8 Oct 2012, Richard Guenther wrote:
>
>> On Mon, Oct 8, 2012 at 11:34 AM, Marc Glisse wrote:
>>>
>>> On Mon, 8 Oct 2012, Richard Guenther wrote:
>>>
>>>>> VEC_COND_EXPR is more co
On Mon, 8 Oct 2012, Richard Guenther wrote:
On Mon, Oct 8, 2012 at 11:34 AM, Marc Glisse wrote:
On Mon, 8 Oct 2012, Richard Guenther wrote:
VEC_COND_EXPR is more complicated. We could for instance require that it
takes as first argument a vector of -1 and 0 (thus <0, !=0 and the neon
th
On Mon, Oct 8, 2012 at 11:34 AM, Marc Glisse wrote:
> On Mon, 8 Oct 2012, Richard Guenther wrote:
>
>>> VEC_COND_EXPR is more complicated. We could for instance require that it
>>> takes as first argument a vector of -1 and 0 (thus <0, !=0 and the neon
>>> thin
On Mon, 8 Oct 2012, Richard Guenther wrote:
VEC_COND_EXPR is more complicated. We could for instance require that it
takes as first argument a vector of -1 and 0 (thus <0, !=0 and the neon
thing are equivalent). Which would leave to decide what the expansion of
vec_cond_expr passes to
s is guaranteed (in generic.texi) to be 0 or 1. So negating
> should be the same as testing with integer_zerop to build -1 or 0. Is it
> just a matter of style (then I am ok), or am I missing a reason which makes
> the negation wrong?
Just a matter of style. Negating is a lot less descriptive
build -1 or
0. Is it just a matter of style (then I am ok), or am I missing a reason
which makes the negation wrong?
The point is we need to define some semantics for vector comparison
results.
Yes. I think a documentation patch should come first: generic.texi is
missing an entry for VEC_CO
target dependent value may
be prefered.
>>> +/* Return true if EXPR is an integer constant representing true. */
>>> +
>>> +bool
>>> +integer_truep (const_tree expr)
>>> +{
>>> + STRIP_NOPS (expr);
>>> +
>>> + switch (TREE
[merging both threads, thanks for the answers]
On Mon, 1 Oct 2012, Richard Guenther wrote:
optabs should be fixed instead, an is_gimple_val condition is implicitely
val != 0.
For vectors, I think it should be val < 0 (with an appropriate cast of val
to a signed integer vector type if necessar
On Fri, Sep 28, 2012 at 6:55 PM, Marc Glisse wrote:
> On Fri, 28 Sep 2012, Richard Guenther wrote:
>
>> On Fri, Sep 28, 2012 at 12:42 AM, Marc Glisse
>> wrote:
>>>
>>> Hello,
>>>
>>> I have been experimenting with generating VEC_COND_EXPR f
On Fri, 28 Sep 2012, Richard Guenther wrote:
On Fri, Sep 28, 2012 at 12:42 AM, Marc Glisse wrote:
Hello,
I have been experimenting with generating VEC_COND_EXPR from the front-end,
and these are just a couple things I noticed.
1) optabs.c requires that the first argument of vec_cond_expr be
On Fri, Sep 28, 2012 at 12:42 AM, Marc Glisse wrote:
> Hello,
>
> I have been experimenting with generating VEC_COND_EXPR from the front-end,
> and these are just a couple things I noticed.
>
> 1) optabs.c requires that the first argument of vec_cond_expr be a
Hello,
I have been experimenting with generating VEC_COND_EXPR from the
front-end, and these are just a couple things I noticed.
1) optabs.c requires that the first argument of vec_cond_expr be a
comparison, but verify_gimple_assign_ternary only checks
is_gimple_condexpr, like for COND_EXPR
Hi,
On Fri, 14 Oct 2011, Richard Guenther wrote:
> But I'm not sure. I think we should delete this check from
> verify_ssa and instead have a corresponding check in
> verify_stmts (which already properly walks trees) that
> for an SSA name we encounter we do have a properly linked use
> (see ver
it's easy to do that for the SSA_NAME
case - at least it's easy without trying to avoid a
FOR_EACH_SSA_USE_OPERAND (, SSA_OP_USE) on the stmt for
each SSA_NAME we encounter).
The gimple.c part is ok.
Thanks,
Richard.
> 2011-10-13 Jakub Jelinek
>
> * gimple.c (walk_stm
also on COND_EXPR/VEC_COND_EXPR comparison operands if they are
ADDR_EXPRs.
* tree-ssa.c (verify_ssa): For COND_EXPR/VEC_COND_EXPR count
SSA_NAMEs in comparison operand as well.
--- gcc/gimple.c.jj 2011-10-13 11:13:39.0 +0200
+++ gcc/gimple.c2011-10-1
_gimple_val) because it embeds another tree code.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> Any serious objections?
None, though the following implements it for both COND_EXPR and
VEC_COND_EXPR.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trun
ested on x86_64-unknown-linux-gnu.
Any serious objections?
Thanks,
Richard.
2011-08-31 Richard Guenther
* expr.c (expand_expr_real_2): Move VEC_COND_EXPR handling here,
from ...
(expand_expr_real_1): ... here.
* gimple-pretty-print.c (dump_ternary_rhs): Handl
201 - 248 of 248 matches
Mail list logo
