[Bug tree-optimization/50596] Problems in vectorization of condition expression

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50596

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |irar at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-10-04 07:04:25 UTC ---
The first problem with vectorization of ori function is similar to why the
first loop below is not vectorized and second is:
float a[1024], b[1024], c[1024], d[1024], e[1024];
void foo (void)
{
  for (int i = 0; i < 1024; i++)
    a[i] = b[i] < c[i] ? d[i] : e[i];
}
void bar (void)
{
  for (int i = 0; i < 1024; i++)
    {
      float d_ = d[i], e_ = e[i];
      a[i] = b[i] < c[i] ? d_ : e_;
    }
}

gcc doesn't think it is ok to load d[i] resp. e[i] unconditionally.  In this
exact case where the loop bound is known and it is an static array of at least
that size it is probably fine, but if d or e was a pointer which might point to
a smaller array, d[i] or e[i] accesses might segfault.

That said, we still have control flow that even ifcvt doesn't fix up even with:
void
f2 ()
{
  for (int i = 0; i != N; ++i)
    {
      float c_ = c[i], d_ = d[i];
      z[i] = a[i] < b[i] && c_ < d_;
    }
}

void
f3 ()
{
  for (int i = 0; i != N; ++i)
    {
      float a_ = a[i], b_ = b[i], c_ = c[i], d_ = d[i];
      z[i] = a_ < b_ && c_ < d_;
    }
}

Note even if there would be no control flow, we'd still give up on bool not
being vectorized.  Bool is problematic, we'd have to use an unsigned char
vector instead (if bool is QImode) for vcond.  But it would be a vcond with
different
datamode and cmpmode size, we'd either need to do it using a V4SFmode/V8SFmode
vcond, then VEC_PACK_TRUNC_EXPR them into V16QImode/V32QImode.

Anyway, I think handling _Bool/bool somehow is now much more urgent than it has
been before, given Kai's/Richard's change to use _Bool/bool much more often in
GIMPLE.  If a bool SSA_NAME just feeds some COND_EXPR, we could just use some
wider type, or we could use wider vcond etc.