[Bug tree-optimization/96244] New: Redudant mask load generated

[Bug tree-optimization/96244] New: Redudant mask load generated

[crazylht at gmail dot com]

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

            Bug ID: 96244
           Summary: Redudant mask load generated
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: crazylht at gmail dot com
  Target Milestone: ---

cat test.c

---
typedef int v8si __attribute__ ((__vector_size__ (32)));
v8si
foo (v8si a, v8si b, v8si c, v8si d)
{
  v8si e;
    for (int i = 0; i != 8; i++)
     e[i] = a[i] > b[i] ? c[i] : d[i];
    return e;
}
---

gcc -Ofast -mavx2 test.c

cat test.c.238t.optimized
---
foo (v8si a, v8si b, v8si c, v8si d)
{
  vector(8) int vect_iftmp.19;
  vector(8) int vect_iftmp.18;
  vector(8) <signed-boolean:32> mask__31.15;
  vector(8) int vect_iftmp.14;
  vector(8) <signed-boolean:32> mask__28.11;

  <bb 2> [local count: 119292720]:
  mask__28.11_40 = b_50(D) < a_53(D);
  vect_iftmp.14_43 = .MASK_LOAD (&c, 32B, mask__28.11_40); ---> redundant
  mask__31.15_44 = b_50(D) >= a_53(D);
  vect_iftmp.18_47 = .MASK_LOAD (&d, 32B, mask__31.15_44); ---> redundant
  vect_iftmp.19_49 = .VCOND (b_50(D), a_53(D), vect_iftmp.18_47,
vect_iftmp.14_43, 110);
  return vect_iftmp.19_49;
---

could be optimized to 
---
vect_iftmp.19_49 = .VCOND (b_50(D), a_53(D), d, c);
---

[Bug tree-optimization/96244] Redudant mask load generated

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-07-20
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |missed-optimization

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
So one thing to note here is that a masked load of a by-value parameter decl
doesn't make much sense since a load from it cannot trap (unless there's
out-of-bound accesses - which I'm not sure we may simply disregard here).

if-conversion sees

VIEW_CONVERT_EXPR<int[8]>(d)[i_16]

and indeed considers it

iftmp.0_11 = VIEW_CONVERT_EXPR<int[8]>(c)[i_17];
tree could trap...

  <bb 3> [local count: 954449105]:
  # RANGE [0, 8] NONZERO 15
  # i_17 = PHI <0(2), i_13(8)>
  # ivtmp_6 = PHI <8(2), ivtmp_4(8)>
  _1 = VIEW_CONVERT_EXPR<int[8]>(a)[i_17];
  _2 = VIEW_CONVERT_EXPR<int[8]>(b)[i_17];

so range-info is one index too pessimistic here.  So IMHO it's not about
"redundant" masked loads, it's about the fact that we end up with loads
at all here.  If c and d would not be register arguments we would have to
perform loads and if they might trap we could not elide the masked load.

[Bug tree-optimization/96244] Redudant mask load generated

[crazylht at gmail dot com]

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

--- Comment #2 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Richard Biener from comment #1)
> so range-info is one index too pessimistic here.  So IMHO it's not about
> "redundant" masked loads, it's about the fact that we end up with loads
> at all here.  If c and d would not be register arguments we would have to
> perform loads and if they might trap we could not elide the masked load.

compared to masked load, load seems to be be more probably eliminated by
backend for this situation.

[Bug tree-optimization/96244] Redudant mask load generated

[crazylht at gmail dot com]

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

Hongtao.liu <crazylht at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Hongtao.liu <crazylht at gmail dot com> ---
.