[Bug middle-end/79161] New: possibly lost DCE optimization
skvadrik at gmail dot com
gcc-bugzilla@gcc.gnu.org
Fri Jan 20 11:17:00 GMT 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79161
Bug ID: 79161
Summary: possibly lost DCE optimization
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: skvadrik at gmail dot com
Target Milestone: ---
Created attachment 40553
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40553&action=edit
a.c
Consider the following example (a.c in attach):
static void f(const char *s)
{
for (; *s++ == '0'; );
}
int main(int argc, char **argv)
{
const char *s0 = argv[1];
for (int x = 0; x < 1000000000; ++x) f(s0);
return 0;
}
Clang thinks this can be optimized to just 'return 0':
$ clang++-3.9 -c -O2 a.c -oa.o && objdump -d a.o
clang-3.9: warning: treating 'c' input as 'c++' when in C++ mode, this behavior
is deprecated
a.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <main>:
0: 31 c0 xor %eax,%eax
2: c3 retq
While GCC doesn't:
$ g++ -c -O2 a.c -oa.o && objdump -d a.o
a.o: file format elf64-x86-64
Disassembly of section .text.startup:
0000000000000000 <main>:
0: 48 8b 4e 08 mov 0x8(%rsi),%rcx
4: ba 00 ca 9a 3b mov $0x3b9aca00,%edx
9: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
10: 48 89 c8 mov %rcx,%rax
13: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
18: 48 83 c0 01 add $0x1,%rax
1c: 80 78 ff 30 cmpb $0x30,-0x1(%rax)
20: 74 f6 je 18 <main+0x18>
22: 83 ea 01 sub $0x1,%edx
25: 75 e9 jne 10 <main+0x10>
27: 31 c0 xor %eax,%eax
29: c3 retq
I'm not sure if optimization is rightful but it looks correct to me. I don't
see any side effects in 'f' function.
More information about the Gcc-bugs
mailing list