[Bug middle-end/100582] New: vectorize failed to generate VEC_COND_EXPR for v32qi

[Bug middle-end/100582] New: vectorize failed to generate VEC_COND_EXPR for v32qi

[crazylht at gmail dot com]

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

            Bug ID: 100582
           Summary: vectorize failed to generate VEC_COND_EXPR for v32qi
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: crazylht at gmail dot com
                CC: hjl.tools at gmail dot com
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu

https://godbolt.org/z/nfdsGPTxj

cat test.c 

v32qi
f2 (v32qi x, v32qi a, v32qi b)
{
    v32qi e;
  for (int i = 0; i != 32; i++)
     e[i] = x[i] ? a[i] : b[i];

  return e;
}

clang can generate vplendvb, gcc doesn't vectorize it.

also clang can generate clean vplendvb for f1.

v32qi
f1 (v32qi x, v32qi a, v32qi b)
{
    v32qi e;
  for (int i = 0; i != 32; i++)
     e[i] = x[i] & -128 ? a[i] : b[i];

  return e;
}

[Bug middle-end/100582] vectorize failed to generate VEC_COND_EXPR for v32qi

[crazylht at gmail dot com]

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

--- Comment #1 from Hongtao.liu <crazylht at gmail dot com> ---
Also for short, not optimal for int.

[Bug middle-end/100582] vectorize failed to generate VEC_COND_EXPR for v32qi

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
   Last reconfirmed|                            |2021-05-17
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
First of all we fail to if-convert because we think

iftmp.0_9 = VIEW_CONVERT_EXPR<unsigned char[32]>(a)[i_15];
tree could trap...

which is because we're concerned about out-of-bound access of 'a' and treat
this as a array-at-struct-end.

[Bug middle-end/100582] vectorize failed to generate VEC_COND_EXPR for v32qi

[crazylht at gmail dot com]

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

--- Comment #3 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Richard Biener from comment #2)
> First of all we fail to if-convert because we think
> 
> iftmp.0_9 = VIEW_CONVERT_EXPR<unsigned char[32]>(a)[i_15];
> tree could trap...
> 
> which is because we're concerned about out-of-bound access of 'a' and treat
> this as a array-at-struct-end.

The tripcount of loop is constant, and the compiler should be able to analyze
that a[i] is not out of bounds, can't scev or vrp helps here?

[Bug middle-end/100582] vectorize failed to generate VEC_COND_EXPR for v32qi

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 17 May 2021, crazylht at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100582
> 
> --- Comment #3 from Hongtao.liu <crazylht at gmail dot com> ---
> (In reply to Richard Biener from comment #2)
> > First of all we fail to if-convert because we think
> > 
> > iftmp.0_9 = VIEW_CONVERT_EXPR<unsigned char[32]>(a)[i_15];
> > tree could trap...
> > 
> > which is because we're concerned about out-of-bound access of 'a' and treat
> > this as a array-at-struct-end.
> 
> The tripcount of loop is constant, and the compiler should be able to analyze
> that a[i] is not out of bounds, can't scev or vrp helps here?

Yes, it works with a fix I am testing right now (still the actual
ranges recorded in the IL are [0, 32]).

diff --git a/gcc/tree.c b/gcc/tree.c
index 01eda553a65..8afba598eb5 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -12550,13 +12550,11 @@ array_at_struct_end_p (tree ref)
       || ! TYPE_MAX_VALUE (TYPE_DOMAIN (atype)))
     return true;

-  if (TREE_CODE (ref) == MEM_REF
-      && TREE_CODE (TREE_OPERAND (ref, 0)) == ADDR_EXPR)
-    ref = TREE_OPERAND (TREE_OPERAND (ref, 0), 0);
-
   /* If the reference is based on a declared entity, the size of the 
array
      is constrained by its given domain.  (Do not trust commons 
PR/69368).  */
-  if (DECL_P (ref)
+  ref = get_base_address (ref);
+  if (ref
+      && DECL_P (ref)
       && !(flag_unconstrained_commons
           && VAR_P (ref) && DECL_COMMON (ref))
       && DECL_SIZE_UNIT (ref)

[Bug middle-end/100582] vectorize failed to generate VEC_COND_EXPR for v32qi

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:e0a5daf81f2c79a0275eccd7c1a25349990a7a4d

commit r12-837-ge0a5daf81f2c79a0275eccd7c1a25349990a7a4d
Author: Richard Biener <rguenther@suse.de>
Date:   Mon May 17 13:56:14 2021 +0200

    middle-end/100582 - fix array_at_struct_end_p for vector indexing

    Vector indexing leaves us with ARRAY_REFs of VIEW_CONVERT_EXPRs,
    sth which array_at_struct_end_p considers a array-at-struct-end
    even when there's an underlying decl visible.  The following fixes
    the latter.

    2021-05-17  Richard Biener  <rguenther@suse.de>

            PR middle-end/100582
            * tree.c (array_at_struct_end_p): Get to the base of the
            reference before looking for the underlying decl.

            * gcc.target/i386/pr100582.c: New testcase.

[Bug middle-end/100582] vectorize failed to generate VEC_COND_EXPR for v32qi

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.