This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug optimization/14824] removing constant assignments from loops not done even for simple conditional expressions
- From: "niemayer at isg dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 2 Apr 2004 15:20:34 -0000
- Subject: [Bug optimization/14824] removing constant assignments from loops not done even for simple conditional expressions
- References: <20040402150422.14824.niemayer@isg.de>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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