[Bug middle-end/60235] Inlining fails with template specialization and -fPIC on Linux AMD64

[Bug middle-end/60235] Inlining fails with template specialization and -fPIC on Linux AMD64

[joker.eph at gmail dot com]

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

--- Comment #1 from Mehdi Amini <joker.eph at gmail dot com> ---
Created attachment 32149
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32149&action=edit
Test Case

[Bug middle-end/60235] New: Inlining fails with template specialization and -fPIC on Linux AMD64

[joker.eph at gmail dot com]

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

            Bug ID: 60235
           Summary: Inlining fails with template specialization and -fPIC
                    on Linux AMD64
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: joker.eph at gmail dot com

Tested with g++-4.6, g++4.8 and current svn:
$ ./gcc-svn-install/bin/g++ --version
g++ (GCC) 4.9.0 20140217 (experimental)


I have a simple C++ code that exhibit this issue: a simple templated function
using one int as template parameter. When a specialization is provided the call
is not inlined, but only when compiling with -fPIC (Ubuntu Linux AMD64). The
issue does not appear with g++-4.8 on OSX. 
Clang does not have this issue, in the benchmark I extracted this minimal test
case from, this missing inline doubles the running time.

To reproduce :

$ g++ inlining.cpp -O2 -S  -fPIC  -DNOSPECIALIZATION
$ grep get inlining.s | grep call
$ g++ inlining.cpp -O2 -S  -fPIC
$ grep get inlining.s | grep call
    call    _Z3getILi0EERdPd@PLT

[Bug middle-end/60235] Inlining fails with template specialization and -fPIC on Linux AMD64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The specialization is a regular function, not comdat, thus it is not
appropriate to inline it at -O2 -fpic, only -O3 is inlining functions
regardless to whether they could be interposed or not, or for -O2 without -fpic
because the symbol can't be interposed.  Or use the inline keyword for the
specialization.

[Bug middle-end/60235] Inlining fails with template specialization and -fPIC on Linux AMD64

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #2)
> The specialization is a regular function, not comdat, thus it is not
> appropriate to inline it at -O2 -fpic, only -O3 is inlining functions
> regardless to whether they could be interposed or not,

Wouldn't that be a wrong-code bug though?

> or for -O2 without
> -fpic because the symbol can't be interposed.  Or use the inline keyword for
> the specialization.

[Bug middle-end/60235] Inlining fails with template specialization and -fPIC on Linux AMD64

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Even at -O3 we inline only functions that either can not be interposed (i.e.
static or -fno-pic) or are known to be same everywhere (comdat and functions
declared inlined). I was considering command line option
-fno-semantic-interposition to control this. Perhaps it is a good idea.

In C++ context I am not really that convinced interposition makes much sense
though. In real life, 99.9% symbols will never be interposed by a symbol with
different semantic and I would say that all of them will be C symbols (malloc).
Given that ELF decided to allow interposition to everything by default, we need
to play safe. 

I tried to discuss in http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01509.html
the consequences of One Definition Rule that IMO prevents two different
implementations of one template coexist in one program. But I lost the case and
the conclusion was that if you fully interpose out one instantiation by
another, OND rule works.

[Bug middle-end/60235] Inlining fails with template specialization and -fPIC on Linux AMD64

[joker.eph at gmail dot com]

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

--- Comment #5 from Mehdi Amini <joker.eph at gmail dot com> ---
(In reply to Jakub Jelinek from comment #2)
> The specialization is a regular function, not comdat, thus it is not
> appropriate to inline it at -O2 -fpic, only -O3 is inlining functions
> regardless to whether they could be interposed or not, or for -O2 without
> -fpic because the symbol can't be interposed.  Or use the inline keyword for
> the specialization.

As I understand your comment, O2 does not inline because of interposition
possibility, but O3 should break interposition? Note that -O3 does not inline
here either by the way.

Considering the (potentially huge) impact on the runtime, there should be a GCC
flag to disable "safe interposition" at compile time, as this "feature" isn't
use most of the time (I think). Unless you want to follow this path, you can
close this bug as "won't fix".

It is interesting to see that Clang does not seem to care about interposition
since the call disappears starting at O2.

[Bug middle-end/60235] Inlining fails with template specialization and -fPIC on Linux AMD64

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Clang doesn't care about lots of things.

Anyway, why don't you make the specialization inline?

[Bug middle-end/60235] Inlining fails with template specialization and -fPIC on Linux AMD64

[joker.eph at gmail dot com]

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

--- Comment #7 from Mehdi Amini <joker.eph at gmail dot com> ---
Yeah I can declare it inline, indeed I already did, I was just considering it a
workaround for a "missing compiler optimization" ;-)

[Bug ipa/60235] Inlining fails with template specialization and -fPIC on Linux AMD64

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60235

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
          Component|middle-end                  |ipa
                 CC|                            |marxin at gcc dot gnu.org
             Status|UNCONFIRMED                 |RESOLVED
   Target Milestone|---                         |5.0

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
-fno-semantic-interposition was added in GCC 5 for the code generation you
want.

[Bug ipa/60235] Inlining fails with template specialization and -fPIC on Linux AMD64

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60235

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #8)
> -fno-semantic-interposition was added in GCC 5 for the code generation you
> want.

I should say it was added by r5-1555.