[Bug c/56727] New: [4.7/4.8] [missed-optimization] Recursive call goes through the PLT unnecessarily

thiago at kde dot org gcc-bugzilla@gcc.gnu.org
Mon Mar 25 19:16:00 GMT 2013


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727

             Bug #: 56727
           Summary: [4.7/4.8] [missed-optimization] Recursive call goes
                    through the PLT unnecessarily
    Classification: Unclassified
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: thiago@kde.org


Consider the following code, compiled with -O2 -fPIC either in C or in C++:

===
void f(TYPE b)
{
    f(0);
}
===

if TYPE is a type of 32- or 64-bit width (int, unsigned, long, long long), GCC
generates the following code (-m32, -mx32 or -m64):

===
f:
.L2:
        jmp     .L2
===

If TYPE is shorter than 32-bit (bool, _Bool, char, short), GCC generates the
following code (-mx32, -m64):

===
f:
        xorl    %edi, %edi
        jmp     f@PLT
===

and much worse code for -m32.

For whatever reason, GCC decided to place the call via the PLT. That's a the
missed optimisation: if this function was called, then the PLT must resolve
back to itself. What's more, since the argument wasn't used, it's also
unnecessary to set it.

The output happens without -fPIC, but in that case there is no PLT.

Tested on:
  GCC 4.7.2 (as shipped by Fedora 17)
  GCC 4.9 (trunk build from 20130318)

This is a contrived example (infinite recursion) that no one would write in
their sane mind. But it might point to missed optimisations in legitimate
recursive functions.



More information about the Gcc-bugs mailing list