* [Bug tree-optimization/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
@ 2014-09-01 13:53 ` ro at gcc dot gnu.org
2014-09-01 14:06 ` ro at gcc dot gnu.org
` (31 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: ro at gcc dot gnu.org @ 2014-09-01 13:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
Rainer Orth <ro at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |5.0
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug tree-optimization/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
2014-09-01 13:53 ` [Bug tree-optimization/62631] " ro at gcc dot gnu.org
@ 2014-09-01 14:06 ` ro at gcc dot gnu.org
2014-09-01 14:26 ` ro at gcc dot gnu.org
` (30 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: ro at gcc dot gnu.org @ 2014-09-01 14:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #1 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 33427
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33427&action=edit
ivopts dump
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug tree-optimization/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
2014-09-01 13:53 ` [Bug tree-optimization/62631] " ro at gcc dot gnu.org
2014-09-01 14:06 ` ro at gcc dot gnu.org
@ 2014-09-01 14:26 ` ro at gcc dot gnu.org
2014-09-01 14:27 ` ro at gcc dot gnu.org
` (29 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: ro at gcc dot gnu.org @ 2014-09-01 14:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #2 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 33428
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33428&action=edit
slp dump
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug tree-optimization/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (2 preceding siblings ...)
2014-09-01 14:26 ` ro at gcc dot gnu.org
@ 2014-09-01 14:27 ` ro at gcc dot gnu.org
2014-09-02 6:00 ` amker.cheng at gmail dot com
` (28 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: ro at gcc dot gnu.org @ 2014-09-01 14:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #3 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 33429
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33429&action=edit
bb-slp-26.c.120t.slp1 dump
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug tree-optimization/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (3 preceding siblings ...)
2014-09-01 14:27 ` ro at gcc dot gnu.org
@ 2014-09-02 6:00 ` amker.cheng at gmail dot com
2014-09-07 19:37 ` danglin at gcc dot gnu.org
` (27 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: amker.cheng at gmail dot com @ 2014-09-02 6:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #4 from bin.cheng <amker.cheng at gmail dot com> ---
Hi Rainer,
This is caused by abnormal huge cost of function call `shiftadd_cost (true,
DImode, 2)'. It returns 100+ cost, resulting in huge cost when representing
use 1 with cand 4:
use 1
compare
in statement if (i_12 <= 99)
at position
type unsigned int
base i_4(D) + 1
step 1
is a biv
related candidates
i_4(D) is invariant (2), eliminable
p_8 is invariant (1), eliminable
candidate 4 (important)
original biv
type int *
base p_8
step 4
base object (void *) p_8
Use 1:
cand cost compl. depends on
0 4 0 inv_expr:0
1 4 0
4 23 0 inv_expr:1 <------huge cost.
5 0 0
6 0 0
8 4 1
I worked out a patch fixing this from ivopt. Because I am not firmiliar with
sparc ISA, could you please help me confirm that below fixed assembly is better
than the original version?
The orignal assembly:
f1:
sllx %o1, 2, %g1
add %o0, %g1, %o0
.LL2:
st %g0, [%o0]
add %o1, 1, %g1
add %o0, 4, %o0
cmp %g1, 99
bleu,pt %icc, .LL2
srl %g1, 0, %o1
jmp %o7+8
nop
.size f1, .-f1
The fixed version assembly:
f1:
.register %g2, #scratch
sllx %o1, 2, %g1
mov 99, %g2
add %o0, %g1, %o0
sub %g2, %o1, %o1
srl %o1, 0, %g1
add %g1, 1, %g1
sllx %g1, 2, %g1
add %o0, %g1, %g1
st %g0, [%o0]
.LL5:
add %o0, 4, %o0
cmp %o0, %g1
blu,a,pt %xcc, .LL5
st %g0, [%o0]
jmp %o7+8
nop
.size f1, .-f1
Though it has larger loop setup code, the loop itself is simplified.
If yes, I will send out the patch for review.
Thanks,
bin
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug tree-optimization/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (4 preceding siblings ...)
2014-09-02 6:00 ` amker.cheng at gmail dot com
@ 2014-09-07 19:37 ` danglin at gcc dot gnu.org
2014-09-11 5:48 ` amker at gcc dot gnu.org
` (26 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: danglin at gcc dot gnu.org @ 2014-09-07 19:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
John David Anglin <danglin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |danglin at gcc dot gnu.org
--- Comment #5 from John David Anglin <danglin at gcc dot gnu.org> ---
Also seen on 32-bit hppa*-*-*. 64-bit is OK.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug tree-optimization/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (5 preceding siblings ...)
2014-09-07 19:37 ` danglin at gcc dot gnu.org
@ 2014-09-11 5:48 ` amker at gcc dot gnu.org
2014-09-11 8:43 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (25 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: amker at gcc dot gnu.org @ 2014-09-11 5:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
amker at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amker at gcc dot gnu.org
--- Comment #6 from amker at gcc dot gnu.org ---
(In reply to Rainer Orth from comment #0)
> The new gcc.dg/tree-ssa/ivopts-lt-2.c test FAILs on 64-bit SPARC (only;
> 32-bit is
> ok):
>
> FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "PHI" 1
> FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "p_[0-9]* <"
> 1
>
> I'm attaching the ivopts dump.
>
> Rainer
Hi,
According to https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00345.html, could
you have a look whether the huge cost returned on sparc64 is as expected?
Thanks very much.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug tree-optimization/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (6 preceding siblings ...)
2014-09-11 5:48 ` amker at gcc dot gnu.org
@ 2014-09-11 8:43 ` ro at CeBiTec dot Uni-Bielefeld.DE
2014-09-12 10:58 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (24 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2014-09-11 8:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #6 from amker at gcc dot gnu.org ---
> (In reply to Rainer Orth from comment #0)
>> The new gcc.dg/tree-ssa/ivopts-lt-2.c test FAILs on 64-bit SPARC (only;
>> 32-bit is
>> ok):
>>
>> FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "PHI" 1
>> FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "p_[0-9]* <"
>> 1
>>
>> I'm attaching the ivopts dump.
[...]
> According to https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00345.html, could
> you have a look whether the huge cost returned on sparc64 is as expected?
I think that's easiest for Eric to say.
Rainer
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug tree-optimization/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (7 preceding siblings ...)
2014-09-11 8:43 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2014-09-12 10:58 ` ro at CeBiTec dot Uni-Bielefeld.DE
2015-02-02 23:22 ` [Bug target/62631] " ebotcazou at gcc dot gnu.org
` (23 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2014-09-12 10:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
>> I think that's easiest for Eric to say.
>
> Not really, I guess you want to debug the function and replay the computation
> since the cost is synthetized and doesn't come directly from the back-end.
I've found what's going on:
* In expmed.c (init_expmed_one_mode), l.194
set_shiftadd_cost (speed, mode, m, set_src_cost (all->shift_add, speed));
with all->shift_add something like
(plus:QI (mult:QI (reg:QI 109 [0])
(const_int 8 [0x8]))
(reg:QI 109 [0]))
* For the mult part, rtx_code calls sparc_rtx_cost, which has
case MULT:
if (float_mode_p)
*total = sparc_costs->float_mul;
else if (! TARGET_HARD_MUL)
*total = COSTS_N_INSNS (25);
On SPARCv9/-m64, TARGET_HARD_MUL is false, so we get the 25*4 = 100 part,
unlike v8, which explains why the test only fails for 64-bit.
Rainer
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (8 preceding siblings ...)
2014-09-12 10:58 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2015-02-02 23:22 ` ebotcazou at gcc dot gnu.org
2015-02-03 9:57 ` ebotcazou at gcc dot gnu.org
` (22 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2015-02-02 23:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEW
Assignee|ebotcazou at gcc dot gnu.org |unassigned at gcc dot gnu.org
--- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
I'm about to install a patch that changes the costs on SPARC 64-bit to:
Use 1:
cand cost compl. depends on
0 4 0 inv_expr:0
1 8 0
4 6 0 inv_expr:1
5 0 0
6 0 0
but this doesn't change the outcome of the test. :-(
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (9 preceding siblings ...)
2015-02-02 23:22 ` [Bug target/62631] " ebotcazou at gcc dot gnu.org
@ 2015-02-03 9:57 ` ebotcazou at gcc dot gnu.org
2015-02-03 10:54 ` amker at gcc dot gnu.org
` (21 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2015-02-03 9:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #13 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Author: ebotcazou
Date: Tue Feb 3 09:56:45 2015
New Revision: 220369
URL: https://gcc.gnu.org/viewcvs?rev=220369&root=gcc&view=rev
Log:
PR target/62631
* config/sparc/sparc.h (TARGET_HARD_MUL): Remove TARGET_V8PLUS.
(TARGET_HARD_MUL32): Rewrite based on TARGET_HARD_MUL.
* config/sparc/sparc.c (sparc_rtx_costs) <MULT>: Return costs based on
int_mulX for integers in 64-bit mode if TARGET_HARD_MUL is not set.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sparc/sparc.c
trunk/gcc/config/sparc/sparc.h
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (10 preceding siblings ...)
2015-02-03 9:57 ` ebotcazou at gcc dot gnu.org
@ 2015-02-03 10:54 ` amker at gcc dot gnu.org
2015-02-04 4:06 ` amker at gcc dot gnu.org
` (20 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: amker at gcc dot gnu.org @ 2015-02-03 10:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #14 from amker at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #12)
> I'm about to install a patch that changes the costs on SPARC 64-bit to:
>
> Use 1:
> cand cost compl. depends on
> 0 4 0 inv_expr:0
> 1 8 0
> 4 6 0 inv_expr:1
> 5 0 0
> 6 0 0
>
> but this doesn't change the outcome of the test. :-(
I will have a look why it fails with refined cost.
Thanks,
bin
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (11 preceding siblings ...)
2015-02-03 10:54 ` amker at gcc dot gnu.org
@ 2015-02-04 4:06 ` amker at gcc dot gnu.org
2015-02-04 11:45 ` ebotcazou at gcc dot gnu.org
` (19 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: amker at gcc dot gnu.org @ 2015-02-04 4:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #15 from amker at gcc dot gnu.org ---
(In reply to amker from comment #14)
> (In reply to Eric Botcazou from comment #12)
> > I'm about to install a patch that changes the costs on SPARC 64-bit to:
> >
> > Use 1:
> > cand cost compl. depends on
> > 0 4 0 inv_expr:0
> > 1 8 0
> > 4 6 0 inv_expr:1
> > 5 0 0
> > 6 0 0
> >
> > but this doesn't change the outcome of the test. :-(
>
> I will have a look why it fails with refined cost.
>
> Thanks,
> bin
The cost of expression "p + ((sizetype)(99 - i_6(D)) + 1) * 4" computed using
normal +/-/* operators on sparc64 is 18, but the cost is 32 if it is computed
as "p + ((sizetype)(99 - i_6(D)) + 1) << 2", which is returned by
get_shiftadd_cost.
>From the assembly code, it seems the computation is expensive on sparc64, I may
skip the test for these architectures if no other solutions.
Thanks.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (12 preceding siblings ...)
2015-02-04 4:06 ` amker at gcc dot gnu.org
@ 2015-02-04 11:45 ` ebotcazou at gcc dot gnu.org
2015-02-04 14:43 ` ebotcazou at gcc dot gnu.org
` (18 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2015-02-04 11:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> The cost of expression "p + ((sizetype)(99 - i_6(D)) + 1) * 4" computed
> using normal +/-/* operators on sparc64 is 18, but the cost is 32 if it is
> computed as "p + ((sizetype)(99 - i_6(D)) + 1) << 2", which is returned by
> get_shiftadd_cost.
How do you get the first number exactly? Note that the costs of shiftadd is
completely skewed (by a factor of 3) because expmed.c computes it as a multadd
instead of a shiftadd:
Breakpoint 2, init_expmed_one_mode (all=0x7fffffffd540, mode=QImode, speed=1)
at /home/eric/svn/gcc/gcc/expmed.c:219
219 set_shiftadd_cost (speed, mode, m, set_src_cost (all->shift_add,
speed));
(gdb) p debug_rtx(all->shift_add)
(plus:QI (mult:QI (reg:QI 109 [0])
(const_int 2 [0x2]))
(reg:QI 109 [0]))
but this should ensure that the costs are roughly the same for the expressions.
> From the assembly code, it seems the computation is expensive on sparc64, I
> may skip the test for these architectures if no other solutions.
The hitch is that the code generated for 32-bit SPARC (where the test passes)
is the optimal one and is also valid for 64-bit SPARC.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (13 preceding siblings ...)
2015-02-04 11:45 ` ebotcazou at gcc dot gnu.org
@ 2015-02-04 14:43 ` ebotcazou at gcc dot gnu.org
2015-02-06 6:20 ` amker at gcc dot gnu.org
` (17 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2015-02-04 14:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #17 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
This looks a generic problem in get_shiftadd_cost to me, it ought to mimic the
algorithms in expmed.c, something like:
@@ -3597,22 +3597,26 @@ get_shiftadd_cost (tree expr, machine_mo
tree multop = TREE_OPERAND (mult, 0);
int m = exact_log2 (int_cst_value (cst));
int maxm = MIN (BITS_PER_WORD, GET_MODE_BITSIZE (mode));
- int sa_cost;
- bool equal_p = false;
+ int as_cost, sa_cost;
+ bool mult_in_op1;
if (!(m >= 0 && m < maxm))
return false;
- if (operand_equal_p (op1, mult, 0))
- equal_p = true;
+ mult_in_op1 = operand_equal_p (op1, mult, 0);
+ as_cost = add_cost (speed, mode) + shift_cost (speed, mode, m);
+
+ /* If the target has a cheap shift-and-add or shift-and-sub instruction,
+ use that in preference to a shift insn followed by an add insn. */
sa_cost = (TREE_CODE (expr) != MINUS_EXPR
? shiftadd_cost (speed, mode, m)
- : (equal_p
+ : (mult_in_op1
? shiftsub1_cost (speed, mode, m)
: shiftsub0_cost (speed, mode, m)));
- res = new_cost (sa_cost, 0);
- res = add_costs (res, equal_p ? cost0 : cost1);
+
+ res = new_cost (MIN (as_cost, sa_cost), 0);
+ res = add_costs (res, mult_in_op1 ? cost0 : cost1);
STRIP_NOPS (multop);
if (!is_gimple_val (multop))
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (14 preceding siblings ...)
2015-02-04 14:43 ` ebotcazou at gcc dot gnu.org
@ 2015-02-06 6:20 ` amker at gcc dot gnu.org
2015-02-06 7:10 ` ebotcazou at gcc dot gnu.org
` (16 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: amker at gcc dot gnu.org @ 2015-02-06 6:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #18 from amker at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #16)
> > The cost of expression "p + ((sizetype)(99 - i_6(D)) + 1) * 4" computed
> > using normal +/-/* operators on sparc64 is 18, but the cost is 32 if it is
> > computed as "p + ((sizetype)(99 - i_6(D)) + 1) << 2", which is returned by
> > get_shiftadd_cost.
>
> How do you get the first number exactly? Note that the costs of shiftadd is
In force_expr_to_var_cost, it calculates the cost in normal way before
returning get_shiftadd_cost.
> completely skewed (by a factor of 3) because expmed.c computes it as a
> multadd instead of a shiftadd:
>
> Breakpoint 2, init_expmed_one_mode (all=0x7fffffffd540, mode=QImode, speed=1)
> at /home/eric/svn/gcc/gcc/expmed.c:219
> 219 set_shiftadd_cost (speed, mode, m, set_src_cost
> (all->shift_add, speed));
> (gdb) p debug_rtx(all->shift_add)
> (plus:QI (mult:QI (reg:QI 109 [0])
> (const_int 2 [0x2]))
> (reg:QI 109 [0]))
>
> but this should ensure that the costs are roughly the same for the
> expressions.
>
> > From the assembly code, it seems the computation is expensive on sparc64, I
> > may skip the test for these architectures if no other solutions.
>
> The hitch is that the code generated for 32-bit SPARC (where the test
> passes) is the optimal one and is also valid for 64-bit SPARC.
The assembly is as below on sparc64:
f1:
.register %g2, #scratch
sllx %o1, 2, %g1
mov 99, %g2
add %o0, %g1, %o0
sub %g2, %o1, %o1
srl %o1, 0, %g1
add %g1, 1, %g1
sllx %g1, 2, %g1
add %o0, %g1, %g1
st %g0, [%o0]
.LL5:
add %o0, 4, %o0
cmp %o0, %g1
blu,a,pt %xcc, .LL5
st %g0, [%o0]
jmp %o7+8
nop
While more efficient on sparc32, as below:
f1:
sll %o1, 2, %g1
sub %g0, %o1, %o1
add %o0, %g1, %o0
sll %o1, 2, %o1
add %o1, 400, %g1
add %o0, %g1, %g1
st %g0, [%o0]
.LL5:
add %o0, 4, %o0
cmp %o0, %g1
blu,a .LL5
st %g0, [%o0]
jmp %o7+8
nop
The bloated pre-header happens on all 64 bits platforms. At least I can
confrim that on aarch64 it is much worse than arm. The difference is, it is
fixed in later compilation passes on aarch64 (I didn't investigate why or how).
I think the cause is, on 64bits platforms, expression
"p + ((sizetype)(99 - i_6(D)) + 1) * 4" != "p + ((sizetype)(100-i_6(D)) * 4"
like on 32 platforms because sizetype has larger precision.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (15 preceding siblings ...)
2015-02-06 6:20 ` amker at gcc dot gnu.org
@ 2015-02-06 7:10 ` ebotcazou at gcc dot gnu.org
2015-02-06 11:18 ` ebotcazou at gcc dot gnu.org
` (15 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2015-02-06 7:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #19 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> The assembly is as below on sparc64:
> f1:
> .register %g2, #scratch
> sllx %o1, 2, %g1
> mov 99, %g2
> add %o0, %g1, %o0
> sub %g2, %o1, %o1
> srl %o1, 0, %g1
> add %g1, 1, %g1
> sllx %g1, 2, %g1
> add %o0, %g1, %g1
> st %g0, [%o0]
> .LL5:
> add %o0, 4, %o0
> cmp %o0, %g1
> blu,a,pt %xcc, .LL5
> st %g0, [%o0]
> jmp %o7+8
> nop
How did you configure the compiler? We're talking about 64-bit SPARC/Solaris
and here's the code actually generated for the time being:
.type f1, #function
.proc 020
f1:
sllx %o1, 2, %g1
add %o0, %g1, %o0
.LL2:
st %g0, [%o0]
add %o1, 1, %g1
add %o0, 4, %o0
cmp %g1, 99
bleu,pt %icc, .LL2
srl %g1, 0, %o1
jmp %o7+8
nop
so it is still suboptimal, hence my generic fix.
>From gcc-bugs-return-476212-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 06 07:22:17 2015
Return-Path: <gcc-bugs-return-476212-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6786 invoked by alias); 6 Feb 2015 07:22:16 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 6728 invoked by uid 48); 6 Feb 2015 07:22:13 -0000
From: "amker at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
Date: Fri, 06 Feb 2015 07:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amker at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-62631-4-eNx22NbpSz@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62631-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62631-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg00545.txt.bz2
Content-length: 1251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #20 from amker at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #19)
> > The assembly is as below on sparc64:
> > f1:
> > .register %g2, #scratch
> > sllx %o1, 2, %g1
> > mov 99, %g2
> > add %o0, %g1, %o0
> > sub %g2, %o1, %o1
> > srl %o1, 0, %g1
> > add %g1, 1, %g1
> > sllx %g1, 2, %g1
> > add %o0, %g1, %g1
> > st %g0, [%o0]
> > .LL5:
> > add %o0, 4, %o0
> > cmp %o0, %g1
> > blu,a,pt %xcc, .LL5
> > st %g0, [%o0]
> > jmp %o7+8
> > nop
>
> How did you configure the compiler? We're talking about 64-bit
> SPARC/Solaris and here's the code actually generated for the time being:
>
> .type f1, #function
> .proc 020
> f1:
> sllx %o1, 2, %g1
> add %o0, %g1, %o0
> .LL2:
> st %g0, [%o0]
> add %o1, 1, %g1
> add %o0, 4, %o0
> cmp %g1, 99
> bleu,pt %icc, .LL2
> srl %g1, 0, %o1
> jmp %o7+8
> nop
>
> so it is still suboptimal, hence my generic fix.
Ouch, my bad. That code is generated because I forced gcc to do the iv
replacement by decreasing the cost. The trunk generates assembly just like
yours.
Thanks.
>From gcc-bugs-return-476213-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 06 08:12:06 2015
Return-Path: <gcc-bugs-return-476213-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3760 invoked by alias); 6 Feb 2015 08:12:06 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 3693 invoked by uid 48); 6 Feb 2015 08:12:02 -0000
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/17982] stop calling assemble_external before final assembly output time
Date: Fri, 06 Feb 2015 08:12:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.0.0
X-Bugzilla-Keywords: FIXME
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: law at redhat dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cc resolution
Message-ID: <bug-17982-4-Y9dzeBGGnv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-17982-4@http.gcc.gnu.org/bugzilla/>
References: <bug-17982-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg00546.txt.bz2
Content-length: 507
https://gcc.gnu.org/bugzilla/show_bug.cgi?id\x17982
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |law at redhat dot com
Resolution|--- |FIXED
--- Comment #36 from Jeffrey A. Law <law at redhat dot com> ---
This was fixed in 2012.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (16 preceding siblings ...)
2015-02-06 7:10 ` ebotcazou at gcc dot gnu.org
@ 2015-02-06 11:18 ` ebotcazou at gcc dot gnu.org
2015-02-06 11:26 ` ebotcazou at gcc dot gnu.org
` (14 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2015-02-06 11:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #21 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Author: ebotcazou
Date: Fri Feb 6 11:17:46 2015
New Revision: 220473
URL: https://gcc.gnu.org/viewcvs?rev=220473&root=gcc&view=rev
Log:
PR target/62631
* tree-ssa-loop-ivopts.c (get_shiftadd_cost): Use the mininum of costs
of shift-add and (add + shift) operations. Rename local variable.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-loop-ivopts.c
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (17 preceding siblings ...)
2015-02-06 11:18 ` ebotcazou at gcc dot gnu.org
@ 2015-02-06 11:26 ` ebotcazou at gcc dot gnu.org
2015-02-06 11:33 ` ebotcazou at gcc dot gnu.org
` (13 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2015-02-06 11:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #22 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
OK, this is fixed on the SPARC, but not on the PA where we still have 2 IVs.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (18 preceding siblings ...)
2015-02-06 11:26 ` ebotcazou at gcc dot gnu.org
@ 2015-02-06 11:33 ` ebotcazou at gcc dot gnu.org
2015-02-06 15:52 ` dave.anglin at bell dot net
` (12 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2015-02-06 11:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #23 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> OK, this is fixed on the SPARC, but not on the PA where we still have 2 IVs.
Correction: we have only one IV on the PA, but it's 'i' and not 'p'.
Dave, is the generated code optimimal on the PA or should the compiler use 'p'?
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (19 preceding siblings ...)
2015-02-06 11:33 ` ebotcazou at gcc dot gnu.org
@ 2015-02-06 15:52 ` dave.anglin at bell dot net
2015-02-07 19:08 ` dave.anglin at bell dot net
` (11 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: dave.anglin at bell dot net @ 2015-02-06 15:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #24 from dave.anglin at bell dot net ---
On 2015-02-06 6:33 AM, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
>
> --- Comment #23 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
>> OK, this is fixed on the SPARC, but not on the PA where we still have 2 IVs.
> Correction: we have only one IV on the PA, but it's 'i' and not 'p'.
>
> Dave, is the generated code optimimal on the PA or should the compiler use 'p'?
>
I'll take a look on the weekend.
Dave
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (20 preceding siblings ...)
2015-02-06 15:52 ` dave.anglin at bell dot net
@ 2015-02-07 19:08 ` dave.anglin at bell dot net
2015-02-07 22:24 ` ebotcazou at gcc dot gnu.org
` (10 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: dave.anglin at bell dot net @ 2015-02-07 19:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #25 from dave.anglin at bell dot net ---
On 2015-02-06, at 6:33 AM, ebotcazou at gcc dot gnu.org wrote:
> Correction: we have only one IV on the PA, but it's 'i' and not 'p'.
>
> Dave, is the generated code optimimal on the PA or should the compiler use 'p'?
The generated code on PA looks optimal to me:
zdep %r25,29,30,%r28
b .L2
ldi 99,%r19
.L6:
zdep %r25,29,30,%r28
.L2:
addl %r26,%r28,%r28
ldo 1(%r25),%r25
comb,>>= %r19,%r25,.L6
stw %r0,0(%r28)
bv,n %r0(%r2)
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (21 preceding siblings ...)
2015-02-07 19:08 ` dave.anglin at bell dot net
@ 2015-02-07 22:24 ` ebotcazou at gcc dot gnu.org
2015-02-07 23:14 ` dave.anglin at bell dot net
` (9 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2015-02-07 22:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #26 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> The generated code on PA looks optimal to me:
>
> zdep %r25,29,30,%r28
> b .L2
> ldi 99,%r19
> .L6:
> zdep %r25,29,30,%r28
> .L2:
> addl %r26,%r28,%r28
> ldo 1(%r25),%r25
> comb,>>= %r19,%r25,.L6
> stw %r0,0(%r28)
> bv,n %r0(%r2)
For most other architectures the BIV (%r25) is eliminated to the GIV (%r28) so
you only have one additive operation in the loop. This happens for 64-bit PA:
.L5:
ldo 4(%r26),%r26
cmpb,*>>,n %r28,%r26,.L5
stw %r0,0(%r26)
bve,n (%r2)
Why couldn't such a code be generated for 32-bit PA too?
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (22 preceding siblings ...)
2015-02-07 22:24 ` ebotcazou at gcc dot gnu.org
@ 2015-02-07 23:14 ` dave.anglin at bell dot net
2015-02-08 14:07 ` amker at gcc dot gnu.org
` (8 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: dave.anglin at bell dot net @ 2015-02-07 23:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #27 from dave.anglin at bell dot net ---
On 2015-02-07, at 5:24 PM, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
>
> --- Comment #26 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
>> The generated code on PA looks optimal to me:
>>
>> zdep %r25,29,30,%r28
>> b .L2
>> ldi 99,%r19
>> .L6:
>> zdep %r25,29,30,%r28
>> .L2:
>> addl %r26,%r28,%r28
>> ldo 1(%r25),%r25
>> comb,>>= %r19,%r25,.L6
>> stw %r0,0(%r28)
>> bv,n %r0(%r2)
>
> For most other architectures the BIV (%r25) is eliminated to the GIV (%r28) so
> you only have one additive operation in the loop. This happens for 64-bit PA:
>
> .L5:
> ldo 4(%r26),%r26
> cmpb,*>>,n %r28,%r26,.L5
> stw %r0,0(%r26)
> bve,n (%r2)
>
> Why couldn't such a code be generated for 32-bit PA too?
There is no reason that I can see.
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (23 preceding siblings ...)
2015-02-07 23:14 ` dave.anglin at bell dot net
@ 2015-02-08 14:07 ` amker at gcc dot gnu.org
2015-02-08 14:09 ` amker at gcc dot gnu.org
` (7 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: amker at gcc dot gnu.org @ 2015-02-08 14:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #28 from amker at gcc dot gnu.org ---
On hppa 32, the two iv uses are:
use 0
address
in statement *p_1 = 0;
at position *p_1
type int *
base p_7
step 4
base object (void *) p_7
related candidates
use 1
compare
in statement if (i_11 <= 99)
at position
type unsigned int
base i_4(D) + 1
step 1
is a biv
related candidates
And the BIV/GIV candidates are:
candidate 3 (important)
original biv
type int *
base p_7
step 4
base object (void *) p_7
candidate 4 (important)
...
candidate 5 (important)
original biv
type unsigned int
base i_4(D)
step 1
The costs table are:
Candidate costs:
cand cost
0 5
1 5
2 5
3 4
4 5
5 4
6 5
7 5
Use 0:
cand cost compl. depends on
0 1 2 1
1 1 0
2 1 1 1
3 1 0
4 3 2 inv_expr:0
5 3 2 inv_expr:0
6 1 1
7 19 3 inv_expr:1
Use 1:
cand cost compl. depends on
0 4 0 inv_expr:2
3 3 0 inv_expr:3
4 0 0
5 0 0
7 4 1
It seems cand3 and cand5 have same level cost, but GCC chooses candidate 5 as
below:
Initial set of candidates:
cost: 9 (complexity 2)
cand_cost: 4
cand_use_cost: 3 (complexity 2)
candidates: 5
use:0 --> iv_cand:5, cost=(3,2)
use:1 --> iv_cand:5, cost=(0,0)
While on other targets, cand 3 is selected.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (24 preceding siblings ...)
2015-02-08 14:07 ` amker at gcc dot gnu.org
@ 2015-02-08 14:09 ` amker at gcc dot gnu.org
2015-02-08 14:59 ` dave.anglin at bell dot net
` (6 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: amker at gcc dot gnu.org @ 2015-02-08 14:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #29 from amker at gcc dot gnu.org ---
(In reply to amker from comment #28)
> On hppa 32, the two iv uses are:
> use 0
> address
> in statement *p_1 = 0;
>
> at position *p_1
> type int *
> base p_7
> step 4
> base object (void *) p_7
> related candidates
> use 1
> compare
> in statement if (i_11 <= 99)
>
> at position
> type unsigned int
> base i_4(D) + 1
> step 1
> is a biv
> related candidates
> And the BIV/GIV candidates are:
> candidate 3 (important)
> original biv
> type int *
> base p_7
> step 4
> base object (void *) p_7
> candidate 4 (important)
> ...
> candidate 5 (important)
> original biv
> type unsigned int
> base i_4(D)
> step 1
>
> The costs table are:
>
> Candidate costs:
> cand cost
> 0 5
> 1 5
> 2 5
> 3 4
> 4 5
> 5 4
> 6 5
> 7 5
> Use 0:
> cand cost compl. depends on
> 0 1 2 1
> 1 1 0
> 2 1 1 1
> 3 1 0
> 4 3 2 inv_expr:0
> 5 3 2 inv_expr:0
> 6 1 1
> 7 19 3 inv_expr:1
>
> Use 1:
> cand cost compl. depends on
> 0 4 0 inv_expr:2
> 3 3 0 inv_expr:3
> 4 0 0
> 5 0 0
> 7 4 1
>
> It seems cand3 and cand5 have same level cost, but GCC chooses candidate 5
Ah, candidate 5 is considered cheaper according to the cost table.
> as below:
> Initial set of candidates:
> cost: 9 (complexity 2)
> cand_cost: 4
> cand_use_cost: 3 (complexity 2)
> candidates: 5
> use:0 --> iv_cand:5, cost=(3,2)
> use:1 --> iv_cand:5, cost=(0,0)
>
> While on other targets, cand 3 is selected.
>From gcc-bugs-return-476361-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Feb 08 14:11:50 2015
Return-Path: <gcc-bugs-return-476361-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25400 invoked by alias); 8 Feb 2015 14:11:50 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 25346 invoked by uid 48); 8 Feb 2015 14:11:46 -0000
From: "hp at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/64467] [5 Regression] 28_regex/traits/char/isctype.cc and wchar_t/isctype.cc
Date: Sun, 08 Feb 2015 14:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hp at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: redi at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64467-4-Jf8QWgqXKb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64467-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64467-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg00694.txt.bz2
Content-length: 472
https://gcc.gnu.org/bugzilla/show_bug.cgi?idd467
--- Comment #9 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
To wit, at r220506 still see:
assertion "!t.isctype('\n', t.lookup_classname(blank,
blank+sizeof(blank)/sizeof(blank[0])-1))" failed: file
"/tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/28_regex/traits/char/isctype.cc",
line 61, function: void test01()
program stopped with signal 6 (Aborted).
Maybe the newlib preprocessor symbol isn't universal?
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (25 preceding siblings ...)
2015-02-08 14:09 ` amker at gcc dot gnu.org
@ 2015-02-08 14:59 ` dave.anglin at bell dot net
2015-02-08 21:44 ` ebotcazou at gcc dot gnu.org
` (5 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: dave.anglin at bell dot net @ 2015-02-08 14:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #30 from dave.anglin at bell dot net ---
On 2015-02-08, at 9:09 AM, amker at gcc dot gnu.org wrote:
> Ah, candidate 5 is considered cheaper according to the cost table.
Is this a problem with insn costs, or a problem in the estimation of the total
cost
for each candidate?
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (26 preceding siblings ...)
2015-02-08 14:59 ` dave.anglin at bell dot net
@ 2015-02-08 21:44 ` ebotcazou at gcc dot gnu.org
2015-02-09 3:24 ` amker at gcc dot gnu.org
` (4 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2015-02-08 21:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #31 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
The test also fails on PowerPC, the 2 IVs are kept by ivopts.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (27 preceding siblings ...)
2015-02-08 21:44 ` ebotcazou at gcc dot gnu.org
@ 2015-02-09 3:24 ` amker at gcc dot gnu.org
2015-02-09 8:11 ` amker at gcc dot gnu.org
` (3 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: amker at gcc dot gnu.org @ 2015-02-09 3:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #32 from amker at gcc dot gnu.org ---
(In reply to dave.anglin from comment #30)
> On 2015-02-08, at 9:09 AM, amker at gcc dot gnu.org wrote:
>
> > Ah, candidate 5 is considered cheaper according to the cost table.
>
> Is this a problem with insn costs, or a problem in the estimation of the
> total cost
> for each candidate?
The total cost I think. Cost in IVOPT is tricky and inaccurate since 1) it
needs to estimate cost of RTL on gimple IR; 2) The rtx expression cost is
computed together with address expression cost, which doesn't happen in other
part of GCC.
I can try to make the case less vulnerable for now. Should we consider this as
a missed optimization since GCC never did the optimization for the case before
(and still not for mentioned targets)?
Thanks,
bin
>
> Dave
> --
> John David Anglin dave.anglin@bell.net
>From gcc-bugs-return-476419-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 09 05:31:18 2015
Return-Path: <gcc-bugs-return-476419-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15224 invoked by alias); 9 Feb 2015 05:31:18 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 15166 invoked by uid 48); 9 Feb 2015 05:31:14 -0000
From: "hp at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c
Date: Mon, 09 Feb 2015 05:31:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hp at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61548-4-MnY9GUXadS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61548-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61548-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg00752.txt.bz2
Content-length: 283
https://gcc.gnu.org/bugzilla/show_bug.cgi?ida548
--- Comment #28 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #27)
> Does the following patch fix the problem?
Yes! Full regtest is underway but this particular FAIL is fixed. Thanks.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (28 preceding siblings ...)
2015-02-09 3:24 ` amker at gcc dot gnu.org
@ 2015-02-09 8:11 ` amker at gcc dot gnu.org
2015-04-22 12:01 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: amker at gcc dot gnu.org @ 2015-02-09 8:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
--- Comment #33 from amker at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #31)
> The test also fails on PowerPC, the 2 IVs are kept by ivopts.
On targets like ARM, the biv(i) is eliminated with biv(p). PowerPC is
different, it only supports pre-increment addressing mode, so GIV(p-4) is
selected for the array reference. GCC now is conservative in iv elimination by
only considering original BIV and nowrapping IVs. Related code is in function
iv_elimination_compare_lt as below:
/* We need to know that the candidate induction variable does not overflow.
While more complex analysis may be used to prove this, for now just
check that the variable appears in the original program and that it
is computed in a type that guarantees no overflows. */
cand_type = TREE_TYPE (cand->iv->base);
if (cand->pos != IP_ORIGINAL || !nowrap_type_p (cand_type))
return false;
Another place we can improve.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (29 preceding siblings ...)
2015-02-09 8:11 ` amker at gcc dot gnu.org
@ 2015-04-22 12:01 ` jakub at gcc dot gnu.org
2015-07-16 9:13 ` rguenth at gcc dot gnu.org
2022-01-09 0:42 ` pinskia at gcc dot gnu.org
32 siblings, 0 replies; 34+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-22 12:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|5.0 |5.2
--- Comment #34 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 5.1 has been released.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (30 preceding siblings ...)
2015-04-22 12:01 ` jakub at gcc dot gnu.org
@ 2015-07-16 9:13 ` rguenth at gcc dot gnu.org
2022-01-09 0:42 ` pinskia at gcc dot gnu.org
32 siblings, 0 replies; 34+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-07-16 9:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|5.2 |5.3
--- Comment #35 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 5.2 is being released, adjusting target milestone to 5.3.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
2014-09-01 13:52 [Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs ro at gcc dot gnu.org
` (31 preceding siblings ...)
2015-07-16 9:13 ` rguenth at gcc dot gnu.org
@ 2022-01-09 0:42 ` pinskia at gcc dot gnu.org
32 siblings, 0 replies; 34+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-01-09 0:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|5.5 |---
^ permalink raw reply [flat|nested] 34+ messages in thread