On 09/09/15 11:31, Alan Lawrence wrote:
Hmmm, hang on. I'm not quite sure what the actual issue/bug is here, but is this
the same issue as my patch 12 "with BE RTL fix"?
(https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01482.html, explanation last at
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02365.html) I pushed this as
r227551 last night and since this reparameterizes the patterns I don't think
your patch will apply to current HEAD.
If my patch is wrong...well, that may be, I haven't understood the issue yet.
In particular, we should expect the vec_unpacks standard pattern to have
different behaviour (from a tree POV), as this is what I find searching for
VEC_UNPACK in tree-vect-stmts.c:
bool
supportable_widening_operation
{
...
switch (code)
{
...
CASE_CONVERT:
c1 = VEC_UNPACK_LO_EXPR;
c2 = VEC_UNPACK_HI_EXPR;
break;
case FLOAT_EXPR:
c1 = VEC_UNPACK_FLOAT_LO_EXPR;
c2 = VEC_UNPACK_FLOAT_HI_EXPR;
break;
case FIX_TRUNC_EXPR:
/* ??? Not yet implemented due to missing VEC_UNPACK_FIX_TRUNC_HI_EXPR/
VEC_UNPACK_FIX_TRUNC_LO_EXPR tree codes and optabs used for
computing the operation. */
return false;
default:
gcc_unreachable ();
}
if (BYTES_BIG_ENDIAN && c1 != VEC_WIDEN_MULT_EVEN_EXPR)
std::swap (c1, c2);
Yes, IIUC this goes against the principle of tree being the same regardless of
underlying endianness.
--Alan
