* [Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
[not found] <bug-61114-4@http.gcc.gnu.org/bugzilla/>
@ 2014-05-08 15:44 ` belagod at gcc dot gnu.org
2014-05-09 11:19 ` rguenth at gcc dot gnu.org
` (12 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: belagod at gcc dot gnu.org @ 2014-05-08 15:44 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
[not found] <bug-61114-4@http.gcc.gnu.org/bugzilla/>
2014-05-08 15:44 ` [Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug belagod at gcc dot gnu.org
@ 2014-05-09 11:19 ` rguenth at gcc dot gnu.org
2014-05-09 12:29 ` belagod at gcc dot gnu.org
` (11 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-05-09 11:19 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
[not found] <bug-61114-4@http.gcc.gnu.org/bugzilla/>
2014-05-08 15:44 ` [Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug belagod at gcc dot gnu.org
2014-05-09 11:19 ` rguenth at gcc dot gnu.org
@ 2014-05-09 12:29 ` belagod at gcc dot gnu.org
2014-05-09 12:33 ` rguenther at suse dot de
` (10 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: belagod at gcc dot gnu.org @ 2014-05-09 12:29 UTC (permalink / raw)
To: gcc-bugs
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 }?
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
[not found] <bug-61114-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2014-05-09 12:29 ` belagod at gcc dot gnu.org
@ 2014-05-09 12:33 ` rguenther at suse dot de
2014-05-09 12:36 ` belagod at gcc dot gnu.org
` (9 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: rguenther at suse dot de @ 2014-05-09 12:33 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
[not found] <bug-61114-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2014-05-09 12:33 ` rguenther at suse dot de
@ 2014-05-09 12:36 ` belagod at gcc dot gnu.org
2014-05-09 12:53 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: belagod at gcc dot gnu.org @ 2014-05-09 12:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
[not found] <bug-61114-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2014-05-09 12:36 ` belagod at gcc dot gnu.org
@ 2014-05-09 12:53 ` rguenth at gcc dot gnu.org
2014-05-09 12:55 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-05-09 12:53 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
[not found] <bug-61114-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2014-05-09 12:53 ` rguenth at gcc dot gnu.org
@ 2014-05-09 12:55 ` rguenth at gcc dot gnu.org
2014-07-29 16:04 ` alan.lawrence at arm dot com
` (6 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-05-09 12:55 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
[not found] <bug-61114-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2014-05-09 12:55 ` rguenth at gcc dot gnu.org
@ 2014-07-29 16:04 ` alan.lawrence at arm dot com
2014-10-27 14:21 ` alalaw01 at gcc dot gnu.org
` (5 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: alan.lawrence at arm dot com @ 2014-07-29 16:04 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
[not found] <bug-61114-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2014-07-29 16:04 ` alan.lawrence at arm dot com
@ 2014-10-27 14:21 ` alalaw01 at gcc dot gnu.org
2014-10-27 14:45 ` alalaw01 at gcc dot gnu.org
` (4 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: alalaw01 at gcc dot gnu.org @ 2014-10-27 14:21 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
[not found] <bug-61114-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2014-10-27 14:21 ` alalaw01 at gcc dot gnu.org
@ 2014-10-27 14:45 ` alalaw01 at gcc dot gnu.org
2014-10-28 10:46 ` ramana at gcc dot gnu.org
` (3 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: alalaw01 at gcc dot gnu.org @ 2014-10-27 14:45 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
[not found] <bug-61114-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2014-10-27 14:45 ` alalaw01 at gcc dot gnu.org
@ 2014-10-28 10:46 ` ramana at gcc dot gnu.org
2015-02-10 2:24 ` collison at gcc dot gnu.org
` (2 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: ramana at gcc dot gnu.org @ 2014-10-28 10:46 UTC (permalink / raw)
To: gcc-bugs
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 ?
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
[not found] <bug-61114-4@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2014-10-28 10:46 ` ramana at gcc dot gnu.org
@ 2015-02-10 2:24 ` collison at gcc dot gnu.org
2015-03-29 14:34 ` mikpelinux at gmail dot com
2015-03-30 10:40 ` rguenth at gcc dot gnu.org
13 siblings, 0 replies; 14+ messages in thread
From: collison at gcc dot gnu.org @ 2015-02-10 2:24 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
[not found] <bug-61114-4@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2015-02-10 2:24 ` collison at gcc dot gnu.org
@ 2015-03-29 14:34 ` mikpelinux at gmail dot com
2015-03-30 10:40 ` rguenth at gcc dot gnu.org
13 siblings, 0 replies; 14+ messages in thread
From: mikpelinux at gmail dot com @ 2015-03-29 14:34 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
[not found] <bug-61114-4@http.gcc.gnu.org/bugzilla/>
` (12 preceding siblings ...)
2015-03-29 14:34 ` mikpelinux at gmail dot com
@ 2015-03-30 10:40 ` rguenth at gcc dot gnu.org
13 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-03-30 10:40 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread