Fold VEC_COND_EXPR to abs, min, max
Mon Mar 18 11:06:00 GMT 2013
On Mon, 18 Mar 2013, Richard Biener wrote:
> On Mon, Mar 18, 2013 at 11:27 AM, Marc Glisse <email@example.com> wrote:
>> On Mon, 18 Mar 2013, Richard Biener wrote:
>>> 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.
> 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
the compiler is not certain that the result is not an lvalue. And the
arguments it can use to prove that are:
* we are in gimple form
* we are not doing C++
* one of the alternatives is not an lvalue
* (new) it is a vec_cond_expr
Apart from changing TREE_CODE == VEC_COND_EXPR to TREE_CODE != COND_EXPR,
I am not sure what to change.
(Looking at the patch, I may have forgotten to check for side effects
somewhere, the tests needed are not exactly the same as for COND_EXPR
since VEC_COND_EXPR is not lazy, I'll check that before resubmitting)
More information about the Gcc-patches