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~
