[PATCH] COND_EXPRs in GIMPLE code and vectorizer

[Roberto COSTA]

Paolo Bonzini wrote:
> 
>> a) if anyone propagates a value anywhere, she should check whether the 
>> propagated value is part of a comparison in a COND_EXPR (and 
>> explicitly fold the comparison, if so).
>> b) in case of a COND_EXPR, fold_ternary (...) in fold-const.c folds 
>> the comparison before doing anything else (currently, it doesn't do it 
>> at all).
>>
>> I'd go for the second alternative.
>> It needs an amendment in your statement "fold and friends don't 
>> recurse on trees..." for the special case of the comparison of a 
>> COND_EXPR, but it avoids explicit checks and folding every time a pass 
>> propagates anything into a COND_EXPR.
> I think this emphasizes a problem with COND_EXPRs in GIMPLE (and 
> VEC_COND_EXPRs too for that matter; this poor aspect of the design has 
> been there forever): that in this case you cannot assume anymore the RHS 
> of a MODIFY_EXPR to be flat (the other case in which this does not hold 
> is load and stores).
> 
> I'd go for the first alternative, writing a fold_gimple_cond_expr 
> function that folds the comparison like this:
> 
> static tree
> fold_gimple_cond_expr (tree temp)
> {
>  tree temp = fold (COND_EXPR_COND (cond_expr));
>  if (temp == COND_EXPR_COND (cond_expr))
>    return fold (cond_expr);
>  else
>    return fold_build3 (COND_EXPR, TREE_TYPE (cond_expr), temp,
>          COND_EXPR_THEN (cond_expr), COND_EXPR_ELSE (cond_expr));
> }
> 
> which can be used in fold_stmt.  Roger will surely have more to say, 
> however.
> 
> (Remember that fold and friends are not GIMPLE-only.  They are used also 
> by front-ends.)
> 
> Paolo

Hello,
I produced the following patch (attached), which I believe takes into 
account Roger's remark and Paolo's suggestion.
I tested it, I bootstrapped with no regressions on i686-pc-linux-gnu.
Please, tell me what do you think. I hope it is ready for approval, I'd 
really like to check these bits and pieces of work about COND_EXPRs 
before I forget about the all matter. :-)

Cheers,
Roberto


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gcc_cond_patch2
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20061114/a2964bc7/attachment.ksh>