public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug optimization/14824] New: removing constant assignments from loops not done even for simple conditional expressions
@ 2004-04-02 15:04 niemayer at isg dot de
2004-04-02 15:20 ` [Bug optimization/14824] " niemayer at isg dot de
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: niemayer at isg dot de @ 2004-04-02 15:04 UTC (permalink / raw)
To: gcc-bugs
If you compile this tiny sample:
---------------------------------------------
extern int y;
const int test(void) {
int i;
int z;
const int x = y;
asm volatile ("testlabel1: ");
for (i = 0; i < x; i++) {
if (x) z = 4;
else z = 5;
}
asm volatile ("testlabel2: ");
return z;
}
------------------------------------------
with "gcc -S -O3 test.c" and have a look at the assembler output, you'll notice
that the assignment of "z = ..." is done x times, though there's absolutely no
chance for the value to change from one iteration to another:
testlabel1:
#NO_APP
testl %ecx, %ecx
jle .L10
movl %ecx, %edx
.p2align 4,,15
.L8:
xorl %eax, %eax
testl %ecx, %ecx
sete %al
addl $4, %eax
decl %edx
jne .L8
.L10:
#APP
testlabel2:
It seems that this is due to the usage of the "if" there, other expressions,
even more complex ones, do not prevent the assignment from being dragged in
front of the loop. The case does not change when using "z = (x)? 4 : 5".
I tried to work around this problem by using a function declared with
__attribute__((const)) instead of the "(x)? 4 : 5" expression, but to no avail -
even such a function will be evaluated x times.
Is there any chance to let the compiler remove such an assignment from the
loop-body?
--
Summary: removing constant assignments from loops not done even
for simple conditional expressions
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: niemayer at isg dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14824
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug optimization/14824] removing constant assignments from loops not done even for simple conditional expressions
2004-04-02 15:04 [Bug optimization/14824] New: removing constant assignments from loops not done even for simple conditional expressions niemayer at isg dot de
@ 2004-04-02 15:20 ` niemayer at isg dot de
2004-04-02 15:31 ` [Bug optimization/14824] inlining hurting performance due to non-removing of constant assignments inside loops containing conditionals niemayer at isg dot de
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: niemayer at isg dot de @ 2004-04-02 15:20 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From niemayer at isg dot de 2004-04-02 15:20 -------
As a followup to myself, the following example may show more visibly why I'm so
confused about the non-optimization: The following code is compiled more
efficiently with "-O3 -fno-inline" than with "-O3" alone, because once the
"internals" of the function with the __attribute__((const)) become invisible to
the compiler, the assignment _is_ removed from the loop body.
The source:
--------------------------------------------------------------------
extern int y;
const int foo(const int x) __attribute__((const));
const int test(void) {
int i;
int z;
const int x = y;
asm volatile ("testlabel1: ");
for (i = 0; i < x; i++) {
/*
if (x) z = 4;
else z = 5;
*/
z = foo(x);
}
asm volatile ("testlabel2: ");
return z;
}
const int foo(const int x) {
if (x) return 4;
return 5;
}
------------------------------------------------
compiled with "-O3", you'll fiend the same unneccessary x-times-assignment as
described above. But once you compile it with "-O3 -fno-inline", the code looks
like:
------------------------------------------------
testlabel1:
#NO_APP
testl %ebx, %ebx
jg .L9
.L8:
#APP
testlabel2:
#NO_APP
movl -4(%ebp), %ebx
movl %ebp, %esp
popl %ebp
ret
.p2align 4,,7
.L9:
movl %ebx, (%esp)
call foo
movl %ebx, %edx
.p2align 4,,15
.L6:
decl %edx
jne .L6
jmp .L8
--------------------------------------------
which is much more efficient for large values of x.
We certainly don't want inlining to hurt performance like this, do we? :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14824
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug optimization/14824] inlining hurting performance due to non-removing of constant assignments inside loops containing conditionals
2004-04-02 15:04 [Bug optimization/14824] New: removing constant assignments from loops not done even for simple conditional expressions niemayer at isg dot de
2004-04-02 15:20 ` [Bug optimization/14824] " niemayer at isg dot de
@ 2004-04-02 15:31 ` niemayer at isg dot de
2004-04-02 16:55 ` pinskia at gcc dot gnu dot org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: niemayer at isg dot de @ 2004-04-02 15:31 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Summary|removing constant |inlining hurting performance
|assignments from loops not |due to non-removing of
|done even for simple |constant assignments inside
|conditional expressions |loops containing
| |conditionals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14824
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug optimization/14824] inlining hurting performance due to non-removing of constant assignments inside loops containing conditionals
2004-04-02 15:04 [Bug optimization/14824] New: removing constant assignments from loops not done even for simple conditional expressions niemayer at isg dot de
2004-04-02 15:20 ` [Bug optimization/14824] " niemayer at isg dot de
2004-04-02 15:31 ` [Bug optimization/14824] inlining hurting performance due to non-removing of constant assignments inside loops containing conditionals niemayer at isg dot de
@ 2004-04-02 16:55 ` pinskia at gcc dot gnu dot org
2004-04-02 16:57 ` pinskia at gcc dot gnu dot org
2004-05-13 20:59 ` [Bug tree-optimization/14824] " pinskia at gcc dot gnu dot org
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-04-02 16:55 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-04-02 16:55 -------
Confirmed, but ....
--
What |Removed |Added
----------------------------------------------------------------------------
Severity|minor |enhancement
Status|UNCONFIRMED |NEW
Ever Confirmed| |1
Keywords| |pessimizes-code
Last reconfirmed|0000-00-00 00:00:00 |2004-04-02 16:55:10
date| |
Target Milestone|--- |tree-ssa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14824
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug optimization/14824] inlining hurting performance due to non-removing of constant assignments inside loops containing conditionals
2004-04-02 15:04 [Bug optimization/14824] New: removing constant assignments from loops not done even for simple conditional expressions niemayer at isg dot de
` (2 preceding siblings ...)
2004-04-02 16:55 ` pinskia at gcc dot gnu dot org
@ 2004-04-02 16:57 ` pinskia at gcc dot gnu dot org
2004-05-13 20:59 ` [Bug tree-optimization/14824] " pinskia at gcc dot gnu dot org
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-04-02 16:57 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-04-02 16:57 -------
It is already fixed on the tree-ssa:
#APP
testlabel1:
#NO_APP
xorl %eax, %eax <--- this is here because z was uninitialized in your example for some cases.
testl %edx, %edx
jle .L7
.p2align 4,,15
.L8:
incl %eax
cmpl %edx, %eax
jl .L8
movl $4, %eax
.L7:
#APP
testlabel2:
#NO_APP
--
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |SUSPENDED
Known to fail| |3.5.0
Known to work| |tree-ssa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14824
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug tree-optimization/14824] inlining hurting performance due to non-removing of constant assignments inside loops containing conditionals
2004-04-02 15:04 [Bug optimization/14824] New: removing constant assignments from loops not done even for simple conditional expressions niemayer at isg dot de
` (3 preceding siblings ...)
2004-04-02 16:57 ` pinskia at gcc dot gnu dot org
@ 2004-05-13 20:59 ` pinskia at gcc dot gnu dot org
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-05-13 20:59 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-05-13 11:46 -------
Fixed for 3.5.0 by the merge of the tree-ssa.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|SUSPENDED |RESOLVED
Component|rtl-optimization |tree-optimization
Resolution| |FIXED
Target Milestone|tree-ssa |3.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14824
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-05-13 11:46 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-04-02 15:04 [Bug optimization/14824] New: removing constant assignments from loops not done even for simple conditional expressions niemayer at isg dot de
2004-04-02 15:20 ` [Bug optimization/14824] " niemayer at isg dot de
2004-04-02 15:31 ` [Bug optimization/14824] inlining hurting performance due to non-removing of constant assignments inside loops containing conditionals niemayer at isg dot de
2004-04-02 16:55 ` pinskia at gcc dot gnu dot org
2004-04-02 16:57 ` pinskia at gcc dot gnu dot org
2004-05-13 20:59 ` [Bug tree-optimization/14824] " pinskia at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).