[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.

[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.

[belagod at gcc dot gnu.org]

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

--- Comment #1 from Tejas Belagod <belagod at gcc dot gnu.org> ---
Sorry I meant it fixes this on aarch64_be.

FAIL: gcc.dg/vect/no-scevccp-outer-7.c execution test

[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think that you simply have a wrong idea of how vectors work.  Vectors in
GENERIC/GIMPLE don't have an "endianess" dependent element order.
That we mis-use BIT_FIELD_REF for vector extraction may confuse you here.

[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.

[belagod at gcc dot gnu.org]

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

--- Comment #3 from Tejas Belagod <belagod at gcc dot gnu.org> ---
Thanks for the clarification. In that case, what element does bit positions
96..127 correspond to in { 120, 0, 0, 0 }?

[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 9 May 2014, belagod at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114
> 
> --- Comment #3 from Tejas Belagod <belagod at gcc dot gnu.org> ---
> Thanks for the clarification. In that case, what element does bit positions
> 96..127 correspond to in { 120, 0, 0, 0 }?

The last 0

[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.

[belagod at gcc dot gnu.org]

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

--- Comment #5 from Tejas Belagod <belagod at gcc dot gnu.org> ---
So, does that mean the folded value 120 is in the wrong place? The fix that I'm
testing swaps the first and last elements of the const vector {120, 0, 0, 0}.

PS: Sorry, my statement "The final folded value is extracted from the LSB which
are bits 32:96 on BE systems" should have read "The final folded value is
extracted from the LSB which are bits 96..127 on BE systems" if that caused
confusion.

[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Tejas Belagod from comment #5)
> So, does that mean the folded value 120 is in the wrong place? The fix that
> I'm testing swaps the first and last elements of the const vector {120, 0,
> 0, 0}.
> 
> PS: Sorry, my statement "The final folded value is extracted from the LSB
> which are bits 32:96 on BE systems" should have read "The final folded value
> is extracted from the LSB which are bits 96..127 on BE systems" if that
> caused confusion.

But that's the bug.  The final value should _always_ be extracted from
0..31.  That is, the folding is perfectly ok given the description of
REDUC_PLUS_EXPR.

So - it looks like the target does something wrong for expansion of
REDUC_PLUS_EXPR.

[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #6)
> (In reply to Tejas Belagod from comment #5)
> > So, does that mean the folded value 120 is in the wrong place? The fix that
> > I'm testing swaps the first and last elements of the const vector {120, 0,
> > 0, 0}.
> > 
> > PS: Sorry, my statement "The final folded value is extracted from the LSB
> > which are bits 32:96 on BE systems" should have read "The final folded value
> > is extracted from the LSB which are bits 96..127 on BE systems" if that
> > caused confusion.
> 
> But that's the bug.  The final value should _always_ be extracted from
> 0..31.  That is, the folding is perfectly ok given the description of
> REDUC_PLUS_EXPR.
> 
> So - it looks like the target does something wrong for expansion of
> REDUC_PLUS_EXPR.

That is, all code conditional on BYTES/WORDS_BIG_ENDIAN in tree-vect* is
suspicious.

[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.

[alan.lawrence at arm dot com]

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

Alan Lawrence <alan.lawrence at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alan.lawrence at arm dot com

--- Comment #8 from Alan Lawrence <alan.lawrence at arm dot com> ---
Here's a simpler testcase that shows the "if (BYTES_BIG_ENDIAN)" in
tree-vect-loop.c is wrong:

static unsigned char in[16];

int
main ( unsigned char argc, char **argv)
{
  unsigned char i = 0;
  unsigned char sum = 0;
  for (i = 0; i < 16; i++)
    in[i] = i;

  for (i = 0; i < 16; i++)
    sum += in[i];

  if (sum != (unsigned char) 120)
    __builtin_printf ("Failed\n");  
}

On AArch64 or x86, compiling with -O3, there is no output.
On AArch64_be or PowerPC (compiling with -O3 -maltivec), it prints "Failed!".

The output from dom2 shows the problem:

Optimizing statement vect_sum_13.10_27 = [reduc_plus_expr] vect_sum_13.8_4;
  Replaced 'vect_sum_13.8_4' with constant '{ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
11, 12, 13, 14, 15 }'
  Folded to: vect_sum_13.10_27 = { 120, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0 };
LKUP STMT vect_sum_13.10_27 = { 120, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0 }
          vect_sum_13.10_27 = { 120, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0 };
==== ASGN vect_sum_13.10_27 = { 120, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0 }
Optimizing statement stmp_sum_13.9_28 = BIT_FIELD_REF <vect_sum_13.10_27, 8,
120>;
  Replaced 'vect_sum_13.10_27' with constant '{ 120, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0 }'
  Folded to: stmp_sum_13.9_28 = 0;
LKUP STMT stmp_sum_13.9_28 = 0
          stmp_sum_13.9_28 = 0;
==== ASGN stmp_sum_13.9_28 = 0
Optimizing statement vect_sum_13.11_29 = stmp_sum_13.9_28;
  Replaced 'stmp_sum_13.9_28' with constant '0'
LKUP STMT vect_sum_13.11_29 = 0
          vect_sum_13.11_29 = 0;
==== ASGN vect_sum_13.11_29 = 0
Optimizing statement if (vect_sum_13.11_29 != 120)
  Replaced 'vect_sum_13.11_29' with constant '0'
  Folded to: if (1 != 0)

[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.

[alalaw01 at gcc dot gnu.org]

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

--- Comment #9 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Mon Oct 27 14:04:43 2014
New Revision: 216736

URL: https://gcc.gnu.org/viewcvs?rev=216736&root=gcc&view=rev
Log:
[Vectorizer] Make REDUC_xxx_EXPR tree codes produce a scalar result

    PR tree-optimization/61114
    * expr.c (expand_expr_real_2): For REDUC_{MIN,MAX,PLUS}_EXPR, add
    extract_bit_field around optab result.

    * fold-const.c (fold_unary_loc): For REDUC_{MIN,MAX,PLUS}_EXPR, produce
    scalar not vector.

    * tree-cfg.c (verify_gimple_assign_unary): Check result vs operand type
    for REDUC_{MIN,MAX,PLUS}_EXPR.

    * tree-vect-loop.c (vect_analyze_loop): Update comment.
    (vect_create_epilog_for_reduction): For direct vector reduction, use
    result of tree code directly without extract_bit_field.

    * tree.def (REDUC_MAX_EXPR, REDUC_MIN_EXPR, REDUC_PLUS_EXPR): Update
    comment.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/expr.c
    trunk/gcc/fold-const.c
    trunk/gcc/tree-cfg.c
    trunk/gcc/tree-vect-loop.c
    trunk/gcc/tree.def

[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.

[alalaw01 at gcc dot gnu.org]

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

--- Comment #10 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Mon Oct 27 14:20:52 2014
New Revision: 216737

URL: https://gcc.gnu.org/viewcvs?rev=216737&root=gcc&view=rev
Log:
Add new optabs for reducing vectors to scalars

    PR tree-optimization/61114
    * doc/md.texi (Standard Names): Add reduc_(plus,[us](min|max))|scal
    optabs, and note in reduc_[us](plus|min|max) to prefer the former.

    * expr.c (expand_expr_real_2): Use reduc_..._scal if available, fall
    back to old reduc_... + BIT_FIELD_REF only if not.

    * optabs.c (optab_for_tree_code): for REDUC_(MAX,MIN,PLUS)_EXPR,
    return the reduce-to-scalar (reduc_..._scal) optab.
    (scalar_reduc_to_vector): New.

    * optabs.def (reduc_smax_scal_optab, reduc_smin_scal_optab,
    reduc_plus_scal_optab, reduc_umax_scal_optab, reduc_umin_scal_optab):
    New.

    * optabs.h (scalar_reduc_to_vector): Declare.

    * tree-vect-loop.c (vectorizable_reduction): Look for optabs reducing
    to either scalar or vector.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/doc/md.texi
    trunk/gcc/expr.c
    trunk/gcc/optabs.c
    trunk/gcc/optabs.def
    trunk/gcc/optabs.h
    trunk/gcc/tree-vect-loop.c

[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |ramana at gcc dot gnu.org
         Resolution|---                         |FIXED
   Target Milestone|---                         |5.0

--- Comment #11 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Resolved then ?

[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.

[collison at gcc dot gnu.org]

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

--- Comment #12 from collison at gcc dot gnu.org ---
Author: collison
Date: Tue Feb 10 02:23:40 2015
New Revision: 220562

URL: https://gcc.gnu.org/viewcvs?rev=220562&root=gcc&view=rev
Log:
2015-02-09  Michael Collison  <michael.collison@linaro.org>

    Backport from trunk r216779.
    2014-10-28  Alan Lawrence  <alan.lawrence@arm.com>

    * expr.c (expand_expr_real_2): Remove code handling VEC_LSHIFT_EXPR.
    * fold-const.c (const_binop): Likewise.
    * cfgexpand.c (expand_debug_expr): Likewise.
    * tree-inline.c (estimate_operator_cost): Likewise.
    * tree-vect-generic.c (expand_vector_operations_1): Likewise.
    * optabs.c (optab_for_tree_code): Likewise.
    (expand_vec_shift_expr): Likewise, update comment.
    * tree.def: Delete VEC_LSHIFT_EXPR, remove comment.
    * optabs.h (expand_vec_shift_expr): Remove comment re. VEC_LSHIFT_EXPR.
    * optabs.def: Remove vec_shl_optab.
    * doc/md.texi: Remove references to vec_shr_m.

2015-02-09  Michael Collison  <michael.collison@linaro.org>

    Backport from trunk r216742.
    2014-10-27  Alan Lawrence  <alan.lawrence@arm.com>

    * config/aarch64/aarch64.c (TARGET_GIMPLE_FOLD_BUILTIN): Define again.
    * config/aarch64/aarch64-builtins.c (aarch64_gimple_fold_builtin):
    Restore, enable for bigendian, update to use __builtin..._scal...

2015-02-09  Michael Collison  <michael.collison@linaro.org>

    Backport from trunk r216741.
    2014-10-27  Alan Lawrence  <alan.lawrence@arm.com>

    * config/aarch64/aarch64-simd-builtins.def (reduc_smax_, reduc_smin_,
    reduc_umax_, reduc_umin_, reduc_smax_nan_, reduc_smin_nan_): Remove.
    (reduc_smax_scal_, reduc_smin_scal_, reduc_umax_scal_,
    reduc_umin_scal_, reduc_smax_nan_scal_, reduc_smin_nan_scal_): New.

    * config/aarch64/aarch64-simd.md
    (reduc_<maxmin_uns>_<mode>): Rename VDQV_S variant to...
    (reduc_<maxmin_uns>_internal<mode>): ...this.
    (reduc_<maxmin_uns>_<mode>): New (VDQ_BHSI).
    (reduc_<maxmin_uns>_scal_<mode>): New (*2).

    (reduc_<maxmin_uns>_v2si): Combine with below, renaming...
    (reduc_<maxmin_uns>_<mode>): Combine V2F with above, renaming...
    (reduc_<maxmin_uns>_internal_<mode>): ...to this (VDQF).

    * config/aarch64/arm_neon.h (vmaxv_f32, vmaxv_s8, vmaxv_s16,
    vmaxv_s32, vmaxv_u8, vmaxv_u16, vmaxv_u32, vmaxvq_f32, vmaxvq_f64,
    vmaxvq_s8, vmaxvq_s16, vmaxvq_s32, vmaxvq_u8, vmaxvq_u16, vmaxvq_u32,
    vmaxnmv_f32, vmaxnmvq_f32, vmaxnmvq_f64, vminv_f32, vminv_s8,
    vminv_s16, vminv_s32, vminv_u8, vminv_u16, vminv_u32, vminvq_f32,
    vminvq_f64, vminvq_s8, vminvq_s16, vminvq_s32, vminvq_u8, vminvq_u16,
    vminvq_u32, vminnmv_f32, vminnmvq_f32, vminnmvq_f64): Update to use
    __builtin_aarch64_reduc_..._scal; remove vget_lane wrapper.

2015-02-09  Michael Collison  <michael.collison@linaro.org>

    Backport from trunk r216738.
    2014-10-27  Alan Lawrence  <alan.lawrence@arm.com>

    * config/aarch64/aarch64-simd-builtins.def
    (reduc_splus_<mode>/VDQF, reduc_uplus_<mode>/VDQF, reduc_splus_v4sf):
    Remove.
    (reduc_plus_scal_<mode>, reduc_plus_scal_v4sf): New.

    * config/aarch64/aarch64-simd.md (reduc_<sur>plus_mode): Remove.
    (reduc_splus_<mode>, reduc_uplus_<mode>, reduc_plus_scal_<mode>): New.

    (reduc_<sur>plus_mode): Change SUADDV -> UNSPEC_ADDV, rename to...
    (aarch64_reduc_plus_internal<mode>): ...this.

    (reduc_<sur>plus_v2si): Change SUADDV -> UNSPEC_ADDV, rename to...
    (aarch64_reduc_plus_internalv2si): ...this.

    (reduc_splus_<mode>/V2F): Rename to...
    (aarch64_reduc_plus_internal<mode>): ...this.

    * config/aarch64/iterators.md
    (UNSPEC_SADDV, UNSPEC_UADDV, SUADDV): Remove.
    (UNSPEC_ADDV): New.
    (sur): Remove elements for UNSPEC_SADDV and UNSPEC_UADDV.

    * config/aarch64/arm_neon.h (vaddv_s8, vaddv_s16, vaddv_s32, vaddv_u8,
    vaddv_u16, vaddv_u32, vaddvq_s8, vaddvq_s16, vaddvq_s32, vaddvq_s64,
    vaddvq_u8, vaddvq_u16, vaddvq_u32, vaddvq_u64, vaddv_f32, vaddvq_f32,
    vaddvq_f64): Change __builtin_aarch64_reduc_[us]plus_... to
    __builtin_aarch64_reduc_plus_scal, remove vget_lane wrapper.

2015-02-09  Michael Collison  <michael.collison@linaro.org>

    Backport from trunk r216737.
    2014-10-27  Alan Lawrence  <alan.lawrence@arm.com>

    PR tree-optimization/61114
    * doc/md.texi (Standard Names): Add reduc_(plus,[us](min|max))|scal
    optabs, and note in reduc_[us](plus|min|max) to prefer the former.

    * expr.c (expand_expr_real_2): Use reduc_..._scal if available, fall
    back to old reduc_...  BIT_FIELD_REF only if not.

    * optabs.c (optab_for_tree_code): for REDUC_(MAX,MIN,PLUS)_EXPR,
    return the reduce-to-scalar (reduc_..._scal) optab.
    (scalar_reduc_to_vector): New.

    * optabs.def (reduc_smax_scal_optab, reduc_smin_scal_optab,
    reduc_plus_scal_optab, reduc_umax_scal_optab, reduc_umin_scal_optab):
    New.

    * optabs.h (scalar_reduc_to_vector): Declare.

    * tree-vect-loop.c (vectorizable_reduction): Look for optabs reducing
    to either scalar or vector.

2015-02-09  Michael Collison  <michael.collison@linaro.org>

    Backport from trunk r216736.
    2014-10-27  Alan Lawrence  <alan.lawrence@arm.com>

    PR tree-optimization/61114
    * expr.c (expand_expr_real_2): For REDUC_{MIN,MAX,PLUS}_EXPR, add
    extract_bit_field around optab result.

    * fold-const.c (fold_unary_loc): For REDUC_{MIN,MAX,PLUS}_EXPR, produce
    scalar not vector.

    * tree-cfg.c (verify_gimple_assign_unary): Check result vs operand type
    for REDUC_{MIN,MAX,PLUS}_EXPR.

    * tree-vect-loop.c (vect_analyze_loop): Update comment.
    (vect_create_epilog_for_reduction): For direct vector reduction, use
    result of tree code directly without extract_bit_field.

    * tree.def (REDUC_MAX_EXPR, REDUC_MIN_EXPR, REDUC_PLUS_EXPR): Update
    comment.

2015-02-09  Michael Collison  <michael.collison@linaro.org>

    Backport from trunk r216734.
    2014-10-27  Alan Lawrence  <alan.lawrence@arm.com>

    * config/aarch64/aarch64.c (TARGET_GIMPLE_FOLD_BUILTIN): Comment out.
    * config/aarch64/aarch64-builtins.c (aarch64_gimple_fold_builtin):
    Remove using preprocessor directis.


Modified:
    branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro
    branches/linaro/gcc-4_9-branch/gcc/cfgexpand.c
    branches/linaro/gcc-4_9-branch/gcc/config/aarch64/aarch64-builtins.c
    branches/linaro/gcc-4_9-branch/gcc/config/aarch64/aarch64-simd-builtins.def
    branches/linaro/gcc-4_9-branch/gcc/config/aarch64/aarch64-simd.md
    branches/linaro/gcc-4_9-branch/gcc/config/aarch64/arm_neon.h
    branches/linaro/gcc-4_9-branch/gcc/config/aarch64/iterators.md
    branches/linaro/gcc-4_9-branch/gcc/doc/md.texi
    branches/linaro/gcc-4_9-branch/gcc/expr.c
    branches/linaro/gcc-4_9-branch/gcc/fold-const.c
    branches/linaro/gcc-4_9-branch/gcc/optabs.c
    branches/linaro/gcc-4_9-branch/gcc/optabs.def
    branches/linaro/gcc-4_9-branch/gcc/optabs.h
    branches/linaro/gcc-4_9-branch/gcc/tree-cfg.c
    branches/linaro/gcc-4_9-branch/gcc/tree-inline.c
    branches/linaro/gcc-4_9-branch/gcc/tree-pretty-print.c
    branches/linaro/gcc-4_9-branch/gcc/tree-vect-generic.c
    branches/linaro/gcc-4_9-branch/gcc/tree-vect-loop.c
    branches/linaro/gcc-4_9-branch/gcc/tree.def

[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.

[mikpelinux at gmail dot com]

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

Mikael Pettersson <mikpelinux at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpelinux at gmail dot com

--- Comment #13 from Mikael Pettersson <mikpelinux at gmail dot com> ---
This wrong-code bug still occurs with gcc-4.9 and gcc-4.8 on powerpc64, but not
with gcc-4.7 so it's a regression there.

[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|Aarch64_64                  |Aarch64_64, powerpc64
      Known to work|                            |5.0

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Well, the fix is certainly too invasive to fix on the branches.  I assume ppc64
works for GCC 5 as well.