This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix fold making valid VEC_PERMs invalid
- From: Richard Biener <rguenther at suse dot de>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, marc dot glisse at inria dot fr
- Date: Thu, 30 Oct 2014 10:22:50 +0100 (CET)
- Subject: Re: [PATCH] Fix fold making valid VEC_PERMs invalid
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1410300952470 dot 12153 at zhemvz dot fhfr dot qr> <20141030091318 dot GZ10376 at tucnak dot redhat dot com>
On Thu, 30 Oct 2014, Jakub Jelinek wrote:
> On Thu, Oct 30, 2014 at 09:56:32AM +0100, Richard Biener wrote:
> > The following patch makes fold_ternary no longer make
> > VEC_PERMs valid for the target invalid. As pointed out
> > in the PR we only need to make sure this doesn't happen
> > after vector lowering.
> Well, even if you do that before vector lowering, if the original
> mask is fine and new one is not, you'd seriously pessimize code.
Note that what fold does here isn't very elaborate - it just
tries hard to make a two-input VEC_PERM a one-input one which
is good for canonicalization and CSE. I'd say that the
optabs.c code should ideally be able to recover the working
variant (or the target expanders should be more clever...).
> How about moving the VEC_PERM_EXPR arg2 == VECTOR_CST folding
> into a separate function with single_arg argument, call it with
> operand_equal_p (op0, op1, 0) initially and call that function again
> if single_arg and !can_vec_perm_p (...), that time with
> single_arg parameter false?
Or how about removing the code instead and doing it during
vector lowering if the original permute is not !can_vec_perm_p?