[Bug target/98697] New: shl not vectorized for v16qi and v8hi with MVE

[Bug target/98697] New: shl not vectorized for v16qi and v8hi with MVE

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98697

            Bug ID: 98697
           Summary: shl not vectorized for v16qi and v8hi with MVE
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

As described in
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562235.html we
currently fail to vectorize

dest[i] = a[i] << b[i]
when the element types are v16qi or v8hi

I've committed the support for shl auto-vectorization for MVE in
g:7432f255b70811dafaf325d94036ac580891de69 (r11-6707)

I haven't yet found why the v16qi and v8hi tests are not vectorized.
With dest[i] = a[i] << b[i] and:
  {
    int i;
    unsigned int i.24_1;
    unsigned int _2;
    int16_t * _3;
    short int _4;
    int _5;
    int16_t * _6;
    short int _7;
    int _8;
    int _9;
    int16_t * _10;
    short int _11;
    unsigned int ivtmp_42;
    unsigned int ivtmp_43;

    <bb 2> [local count: 119292720]:

    <bb 3> [local count: 954449105]:
    i.24_1 = (unsigned int) i_23;
    _2 = i.24_1 * 2;
    _3 = a_15(D) + _2;
    _4 = *_3;
    _5 = (int) _4;
    _6 = b_16(D) + _2;
    _7 = *_6;
    _8 = (int) _7;
    _9 = _5 << _8;
    _10 = dest_17(D) + _2;
    _11 = (short int) _9;
    *_10 = _11;
    i_19 = i_23 + 1;
    ivtmp_42 = ivtmp_43 - 1;
    if (ivtmp_42 != 0)
      goto <bb 5>; [87.50%]
    else
      goto <bb 4>; [12.50%]

    <bb 5> [local count: 835156386]:
    goto <bb 3>; [100.00%]

    <bb 4> [local count: 119292720]:
    return;

  }
the vectorizer says:
mve-vshl.c:37:96: note:   ==> examining statement: _5 = (int) _4;
mve-vshl.c:37:96: note:   vect_is_simple_use: operand *_3, type of def:
internal
mve-vshl.c:37:96: note:   vect_is_simple_use: vectype vector(8) short int
mve-vshl.c:37:96: missed:   conversion not supported by target.
mve-vshl.c:37:96: note:   vect_is_simple_use: operand *_3, type of def:
internal
mve-vshl.c:37:96: note:   vect_is_simple_use: vectype vector(8) short int
mve-vshl.c:37:96: note:   vect_is_simple_use: operand *_3, type of def:
internal
mve-vshl.c:37:96: note:   vect_is_simple_use: vectype vector(8) short int
mve-vshl.c:37:117: missed:   not vectorized: relevant stmt not supported: _5 =
(int) _4;
mve-vshl.c:37:96: missed:  bad operation or unsupported loop bound.
mve-vshl.c:37:96: note:  ***** Analysis failed with vector mode V8HI

[Bug target/98697] shl not vectorized for v16qi and v8hi with MVE

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98697

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
it looks like unpack from short int to int is not supported?  That is,
the usual issue is that a[i] << b[i] is a shift of int << ... because
of C integral promotion rules.

[Bug target/98697] shl not vectorized for v16qi and v8hi with MVE

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98697

--- Comment #2 from Christophe Lyon <clyon at gcc dot gnu.org> ---
Why would this be different from right shift, where we don't miss the
optimization?

[Bug target/98697] shl not vectorized for v16qi and v8hi with MVE

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98697

--- Comment #3 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Christophe Lyon from comment #2)
> Why would this be different from right shift, where we don't miss the
> optimization?

It's supposed to be handled in vect_recog_over_widening_pattern, but failed
since it may overflow?

[Bug target/98697] shl not vectorized for v16qi and v8hi with MVE

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98697

--- Comment #4 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Hongtao.liu from comment #3)
> (In reply to Christophe Lyon from comment #2)
> > Why would this be different from right shift, where we don't miss the
> > optimization?
> 
> It's supposed to be handled in vect_recog_over_widening_pattern, but failed
> since it may overflow?

x86 also have same problem for vpsllvw.