Re: Fold VEC_COND_EXPR to abs, min, max

[Marc Glisse]

On Mon, 18 Mar 2013, Richard Biener wrote:

2013-03-17  Marc Glisse  <marc.gli...@inria.fr>
gcc/
        * fold-const.c (fold_cond_expr_with_comparison): Use build_zero_cst.
        VEC_COND_EXPR cannot be lvalues.
        (fold_ternary_loc) <VEC_COND_EXPR>: Call
fold_cond_expr_with_comparison.

gcc/cp/
        * call.c (build_conditional_expr_1): Fold VEC_COND_EXPR.

gcc/testsuite/
        * g++.dg/ext/vector21.C: New testcase.

@@ -4662,21 +4662,22 @@ fold_cond_expr_with_comparison (location
      expressions will be false, so all four give B.  The min()
      and max() versions would give a NaN instead.  */
   if (!HONOR_SIGNED_ZEROS (TYPE_MODE (type))
       && operand_equal_for_comparison_p (arg01, arg2, arg00)
       /* Avoid these transformations if the COND_EXPR may be used
         as an lvalue in the C++ front-end.  PR c++/19199.  */
       && (in_gimple_form
          || (strcmp (lang_hooks.name, "GNU C++") != 0
              && strcmp (lang_hooks.name, "GNU Objective-C++") != 0)
          || ! maybe_lvalue_p (arg1)
-         || ! maybe_lvalue_p (arg2)))
+         || ! maybe_lvalue_p (arg2)
+         || TREE_CODE (TREE_TYPE (arg1)) == VECTOR_TYPE))

You mean that the 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 
ternary variant of BIT_AND_EXPR.

Btw, instead of copying this whole block I'd prefer

    case COND_EXPR:
    case VEC_COND_EXPR:
        ... common cases...

        /* ???  Fixup the code below for VEC_COND_EXRP.  */
        if (code == VEC_COND_EXPR)
          break;

Makes sense, I'll rework the patch.

Thanks,

--
Marc Glisse