This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/79161] New: possibly lost DCE optimization


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]