Fold VEC_COND_EXPR to abs, min, max

Marc Glisse marc.glisse@inria.fr
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 <marc.glisse@inria.fr> 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)

-- 
Marc Glisse



More information about the Gcc-patches mailing list