Adapt one fold-const optimization for vectors

Marc Glisse marc.glisse@inria.fr
Wed Oct 31 13:11:00 GMT 2012


On Wed, 31 Oct 2012, Jakub Jelinek wrote:

> On Tue, Oct 30, 2012 at 01:14:40PM +0100, Marc Glisse wrote:
>> On Tue, 30 Oct 2012, Marek Polacek wrote:
>>
>>> On Tue, Oct 30, 2012 at 08:05:13AM +0100, Marc Glisse wrote:
>>>> Hello,
>>>>
>>>> one more optimization that needed help for vectors, it crashed on
>>>> (x<y)<0. Because of PR 55001, testcases are awkward to add (I could
>>>> do a x86-only one if needed).
>>>>
>>>> bootstrap+testsuite.
>>>>
>>>> 2012-10-30  Marc Glisse  <marc.glisse@inria.fr>
>>>>
>>>> 	* fold-const.c (fold_binary_op_with_conditional_arg): Handle vectors.
>>>> 	(fold_binary_loc): call it for VEC_COND_EXPR.
>
> Capital C instead of lowercase.

Ok.

>>> Patch missing?
>>
>> Indeed, thanks for the notice.
>
> This regressed
> FAIL: g++.dg/other/vector-compare.C (internal compiler error)
> FAIL: g++.dg/other/vector-compare.C (test for excess errors)
> on i686-linux.

Thanks. I am surprised, I expected this problem to happen only for code 
where the optimization was previously crashing. Actually, before my patch, 
the code was apparently silently miscompiled. We appear to be missing code 
that would check that the result of a vector operation is a vector (in 
particular not a boolean).

> The problem is that tree-vect-generic.c doesn't expand
> BLKmode VEC_COND_EXPR piecewise.  So, either fold-const on this optimization
> needs to test whether expand_vec_cond_expr_p is true for the chosen
> pair of comparison type and operand type, or tree-vect-generic.c needs to be
> tought to expand VEC_COND_EXPR piecewise if expand_vec_cond_expr_p is not
> true for the particular VEC_COND_EXPR.

The second one is needed anyway (that's PR 55001, which I mention in my 
email). One quick hack as long as it isn't done would be to replace:
     cond_code = VEC_COND_EXPR;
with
     return NULL_TREE;
(and a comment linking to PR55001 and this conversation).

Now I am a bit afraid that the vector lowering pass is not the last one, 
and some later pass might call fold and re-create unexpandable vector 
operations, in which case the first option might also be needed... but I 
hope not.

-- 
Marc Glisse



More information about the Gcc-patches mailing list