[Bug tree-optimization/98221] [10/11 regression] Wrong unpack operation emitted in tree-ssa-forwprop.c

2020-12-10 Thread rguenth at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98221

--- Comment #4 from Richard Biener  ---
(In reply to Andreas Krebbel from comment #3)
> tree-vect-loop-manip.c: vect_maybe_permute_loop_masks also emits
> VEC_UNPACKS_HI/LO dependent on BYTES_BIG_ENDIAN.
> 
> What is the expectation wrt the meaning of hi/lo in RTL standard names? I
> couldn't find it clearly documented for this either. Well, for things like
> 'smulm3_highpart' we say it is about the 'most significant half' but I don't
> see anything for the vector hi/lo.

It would be nice to clarify this indeed.  Like for ppc64le with "big-endian"
vector ops the only chance is to have the target emulate litte-endian
vector ops given the 1:1 match on BYTES_BIG_ENDIAN.

Note in supportable_widening_operation we also swap

case VEC_WIDEN_MULT_EVEN_EXPR:
  /* Support the recursion induced just above.  */
  c1 = VEC_WIDEN_MULT_EVEN_EXPR;
  c2 = VEC_WIDEN_MULT_ODD_EXPR;
  break;

and I wonder if we can build a wrong-code testcase from that (unless even/odd
interpretation also depends on BYTES_BIG_ENDIAN).  s390 does seem to implement
those at least.

[Bug tree-optimization/98221] [10/11 regression] Wrong unpack operation emitted in tree-ssa-forwprop.c

2020-12-10 Thread krebbel at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98221

--- Comment #3 from Andreas Krebbel  ---
tree-vect-loop-manip.c: vect_maybe_permute_loop_masks also emits
VEC_UNPACKS_HI/LO dependent on BYTES_BIG_ENDIAN.

What is the expectation wrt the meaning of hi/lo in RTL standard names? I
couldn't find it clearly documented for this either. Well, for things like
'smulm3_highpart' we say it is about the 'most significant half' but I don't
see anything for the vector hi/lo.

[Bug tree-optimization/98221] [10/11 regression] Wrong unpack operation emitted in tree-ssa-forwprop.c

2020-12-10 Thread rsandifo at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98221

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
(In reply to Richard Biener from comment #1)
> But all GIMPLE operates on "GIMPLE lane order" so this is a defect in how
> the backend handles those tree codes at expansion time?
I can never remember which way round it is and always have
to look it up, but: for better or (probably) worse, I think the hi/lo
classification applies to the high/low parts of registers (MSB/LSB)
rather than high/low lanes.

Personally I'd prefer if it was the other way around, but that's
not going to be easy to change.

[Bug tree-optimization/98221] [10/11 regression] Wrong unpack operation emitted in tree-ssa-forwprop.c

2020-12-10 Thread rguenth at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98221

Richard Biener  changed:

   What|Removed |Added

Summary|[11 regression] Wrong   |[10/11 regression] Wrong
   |unpack operation emitted in |unpack operation emitted in
   |tree-ssa-forwprop.c |tree-ssa-forwprop.c
   Target Milestone|11.0|10.3