This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix up VEC_INTERLEAVE_*_EXPR folding and expansion for big endian (PR tree-optimization/51074)
- From: Richard Henderson <rth at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Guenther <rguenther at suse dot de>, gcc-patches at gcc dot gnu dot org, David Miller <davem at davemloft dot net>, sje at cup dot hp dot com, dje dot gcc at gmail dot com
- Date: Tue, 22 Nov 2011 09:37:07 -0800
- Subject: Re: [PATCH] Fix up VEC_INTERLEAVE_*_EXPR folding and expansion for big endian (PR tree-optimization/51074)
- References: <20111122143056.GR27242@tyan-ft48-01.lab.bos.redhat.com>
On 11/22/2011 06:30 AM, Jakub Jelinek wrote:
> PR tree-optimization/51074
> * fold-const.c (fold_binary_loc): Fix up VEC_INTERLEAVE_*_EXPR
> handling for BYTES_BIG_ENDIAN.
> * optabs.c (can_vec_perm_for_code_p): Likewise.
>
> * gcc.dg/vect/pr51074.c: New test.
As we discussed on IRC, I think this is ok for the short term.
However, this does mean that the representation of vec_interleave_*_expr is wrong on *all* big-endian targets, and the only reason we havn't seen this before now is that we don't generally get to fold them.
The only good way to clean up this mixup is to remove vec_interleave_*_expr entirely, and always use vec_perm_expr, whose semantics are not in doubt. This may sound like it's too heavy-weight for stage3, but the situation at the moment is that we're relying on rtl-folding not to occur for these targets.
If we don't change the vectorizer and the targets for gcc 4.7, then I think we should disable rtl folding of vec_select and vec_merge, as these are the rtl patterns used to implement vec_interleave.
Thoughts?
r~