[Bug c++/51680] New: g++ 4.7 fails to inline trivial template stuff

[Bug c++/51680] New: g++ 4.7 fails to inline trivial template stuff

[miles at gnu dot org]

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

             Bug #: 51680
           Summary: g++ 4.7 fails to inline trivial template stuff
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: miles@gnu.org


Given the following source code (and options "-O2 -S"):

   extern void process (float);

   template<typename Fun, typename T>
   void process_fun_at (const Fun &fun, T x)
   {
     process (fun (x));
   }

   static float add1 (float x)
   {
     return x + 1;
   }

   void test (float i)
   {
     process_fun_at (add1, i);
   }

g++ 4.6 (and clang++ 3.0) produce the obvious output, inlining the template
function "process_fun_at", and the function "add1":

           .globl       test(float)
   test(float):
           addss        .LC0(%rip), %xmm0
           jmp  process(float)
   .LC0:
           .long        1065353216
           .ident       "GCC: (Debian 4.6.2-9) 4.6.2"


However g++ 4.7 produces much more awkward code, inlining nothing:

   add1(float):
           addss        .LC0(%rip), %xmm0
           ret

   void process_fun_at<float (float), float>(float ( const&)(float), float):
           subq $8, %rsp
           call *%rdi
           addq $8, %rsp
           jmp  process(float)

           .globl       test(float)
   test(float):
           movl add1(float), %edi
           jmp  void process_fun_at<float (float), float>(float (
const&)(float), float)
   .LC0:
           .long        1065353216
           .ident       "GCC: (Debian 20111210-1) 4.7.0 20111210 (experimental)
[trunk revision 182188]"


If I add the keyword "inline" to the declaration of the "process_fun_at"
template function, then g++ 4.7 inlines everything and produces the same result
as 4.6.

However my impression is that given such very simple input, it should do this
inlining automatically.

g++ version is:
(Debian 20111210-1) 4.7.0 20111210 (experimental) [trunk revision 182188]

Thanks,

-miles

[Bug c++/51680] g++ 4.7 fails to inline trivial template stuff

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

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

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-12-27 11:14:05 UTC ---
This seems somehow intended (I don't think I would have expected process_fun_at
to be inlined at -O2 (vs -O3), missing the inline keyword). Let's ask Honza.

[Bug c++/51680] g++ 4.7 fails to inline trivial template stuff

[miles at gnu dot org]

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

--- Comment #2 from miles at gnu dot org 2011-12-27 13:54:38 UTC ---
Hmm, I dunno, my impression is that people expect that template'd code is, in
general "more inlined" -- templates are often used kind of as macro replacement
in C++ -- especially for very trivial cases like this one...

[Bug c++/51680] g++ 4.7 fails to inline trivial template stuff

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-12-27 14:15:06 UTC ---
To be honest, this kind of expectation is completely new to me. I may be wrong,
but I don't think we have anything dealing specially with templates from the
inlining point of view.

[Bug c++/51680] g++ 4.7 fails to inline trivial template stuff

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-12-27 19:14:54 UTC ---
This changed with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172609

[Bug c++/51680] g++ 4.7 fails to inline trivial template stuff

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-28 00:42:16 UTC ---
(In reply to comment #3)
> To be honest, this kind of expectation is completely new to me.

Me too. Templates are about genericity, not inlining.

[Bug c++/51680] g++ 4.7 fails to inline trivial template stuff

[miles at gnu dot org]

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

--- Comment #6 from miles at gnu dot org 2011-12-28 01:04:05 UTC ---
Well, it's just an impression ... :]

I think one reason is that unlike normal functions, template functions are
implicitly sort of "local" (by necessity), in that they can have a definition
in many compilation units without causing a link conflict.  To get this effect
for normal functions, one must use the "static" or "inline" keywords -- so the
impression (rightly or wrongly) is that template functions definitions are like
one of those.

... and of course if a [normal] function definition has "static" or "inline"
attached, gcc does do inlining differently.  As I mentioned in my original
report, gcc 4.6, seems to treat template functions this way w/r/t inlining, as
if they were static.[*]

On another note, I'd kinda expect gcc these days to be making pretty reasonable
decisions about inlining even without hints; that's why I'm surprised at
behavior of my example, where the functions involved are so trivial that
inlining seems almost always a good bet...

[*] For instance, here's a "normal function" version of my example:   extern
void process (float);

   void process_fun_at (float (&fun)(float), float x)
   {
     process (fun (x));
   }

   static float add1 (float x)
   {
     return x + 1;
   }

   void test (float i)
   {
     process_fun_at (add1, i);
   }

gcc 4.6 will compile this differently if "process_fun_at" is declared "static";
if it's static, everything gets inlined, otherwise, nothing is inlined.  gcc
4.6 completely inlines the original template example with no special
declaration for the "process_fun_at" template function, meaning it's being
treated kind of like it's static for inlining purposes.

gcc 4.7 compiles the normal-function example the same as gcc 4.6 for both
static and non-static cases, but _doesn't_ inline the template version by
default.  So if nothing else, this is a change in behavior from gcc 4.6;
whether it's good or bad I dunno.

[and yeah, I know inlining heuristics are a big ball of hair that nobody wants
to mess with if they can help it.... sorry.... :]

Thanks,

-miles

[Bug c++/51680] g++ 4.7 fails to inline trivial template stuff

[marc.glisse at normalesup dot org]

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

Marc Glisse <marc.glisse at normalesup dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marc.glisse at normalesup
                   |                            |dot org

--- Comment #7 from Marc Glisse <marc.glisse at normalesup dot org> 2011-12-28 13:44:16 UTC ---
With g++-4.6, -O1 -finline-small-functions already inlines everything, so maybe
the definition of "small" somehow changed a bit? g++-4.7 -fdump-ipa-all says
that it doesn't inline because "function not declared inline and code size
would grow". g++-4.6 only tells me that the code size was unchanged by inlining
the 2 calls.

[Bug c++/51680] g++ 4.7 fails to inline trivial template stuff

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-28 20:09:32 UTC ---
(In reply to comment #6)
> Well, it's just an impression ... :]
> 
> I think one reason is that unlike normal functions, template functions are
> implicitly sort of "local" (by necessity), in that they can have a definition
> in many compilation units without causing a link conflict.  To get this effect
> for normal functions, one must use the "static" or "inline" keywords -- so the
> impression (rightly or wrongly) is that template functions definitions are like
> one of those.


Inline functions and templates both have vague linkage, which is how they avoid
multiple definitions. That has nothing to do with inlining.

[Bug tree-optimization/51680] [4.7 Regression] g++ 4.7 fails to inline trivial template stuff

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-12-30
          Component|c++                         |tree-optimization
   Target Milestone|---                         |4.7.0
            Summary|g++ 4.7 fails to inline     |[4.7 Regression] g++ 4.7
                   |trivial template stuff      |fails to inline trivial
                   |                            |template stuff
     Ever Confirmed|0                           |1

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-12-30 23:40:41 UTC ---
  not inlinable: void test(float)/1 -> void process_fun_at(const Fun&, T) [with
Fun = float(float); T = float]/2, function not declared inline and code size
would grow


Confirmed, GCC should have inlined this function.  The patch which caused this
should not have changed this case.

[Bug tree-optimization/51680] [4.7 Regression] g++ 4.7 fails to inline trivial template stuff

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-02 10:43:03 UTC ---
Analyzing function body size: float add1(float)
                Accounting size:2.00, time:0.00 on new predicate:(not inlined)

 BB 2 predicate:(true)
  D.2207_2 = x_1(D) + 1.0e+0;
                freq:1.00 size:  1 time:  1
                Accounting size:1.00, time:1.00 on predicate:(true)
  return D.2207_2;
                freq:1.00 size:  1 time:  2
                Will be eliminated by inlining
                Accounting size:1.00, time:2.00 on predicate:(not inlined)

Inline summary for float add1(float)/0 inlinable
  self time:       3
  global time:     0
  self size:       4
  global size:     0
  self stack:      0
  global stack:    0
    size:1.000000, time:1.000000, predicate:(true)
    size:3.000000, time:2.000000, predicate:(not inlined)
  calls:

float add1(float) (float x)
{
  float D.2207;

<bb 2>:
  D.2207_2 = x_1(D) + 1.0e+0;
  return D.2207_2;

}


Analyzing function body size: void process_fun_at(const Fun&, T) [with Fun =
float(float); T = float]
                Accounting size:2.00, time:0.00 on new predicate:(not inlined)

 BB 2 predicate:(true)
  D.2206_3 = fun_1(D) (x_2(D));
                freq:1.00 size:  5 time: 17
  D.2205_4 = D.2206_3;
                freq:1.00 size:  0 time:  0
  process (D.2205_4);
                freq:1.00 size:  2 time: 11
  return;
                freq:1.00 size:  1 time:  2
                Will be eliminated by inlining
                Accounting size:1.00, time:2.00 on predicate:(not inlined)

Inline summary for void process_fun_at(const Fun&, T) [with Fun = float(float);
T = float]/2 inlinable
  self time:       30
  global time:     0
  self size:       10
  global size:     0
  self stack:      0
  global stack:    0
    size:0.000000, time:0.000000, predicate:(true)
    size:3.000000, time:2.000000, predicate:(not inlined)
  calls:
    void process(float)/3 function body not available
      loop depth: 0 freq:1000 size: 2 time: 11 callee size: 0 stack: 0
    indirect call loop depth: 0 freq:1000 size: 5 time: 17

Inline summary for void test(float)/1 inlinable
  self time:       14
  global time:     0
  self size:       6
  global size:     0
  self stack:      0
  global stack:    0
    size:0.000000, time:0.000000, predicate:(true)
    size:3.000000, time:2.000000, predicate:(not inlined)
  calls:
    void process_fun_at(const Fun&, T) [with Fun = float(float); T = float]/2
function not considered for inlining
      loop depth: 0 freq:1000 size: 3 time: 12 callee size: 5 stack: 0

void test(float) (float i)
{
<bb 2>:
  process_fun_at<float(float), float> (add1, i_1(D));
  return;

}

during early inlining we decide:

;; Function void test(float) (_Z4testf, funcdef_no=2, decl_uid=2196,
cgraph_uid=1)

Considering inline candidate void process_fun_at(const Fun&, T) [with Fun =
float(float); T = float].
   Estimating body: void process_fun_at(const Fun&, T) [with Fun =
float(float); T = float]/2
   Known to be false: not inlined
   size:7 time:28
   Estimating body: void process_fun_at(const Fun&, T) [with Fun =
float(float); T = float]/2
   Known to be false: not inlined
   size:7 time:28
  will not early inline: void test(float)/1->void process_fun_at(const Fun&, T)
[with Fun = float(float); T = float]/2, callee is not leaf and code would grow
by 4
Iterations: 0
void test(float) (float i)
{
<bb 2>:
  process_fun_at<float(float), float> (add1, i_1(D));

because we'd replace one call with two.  Not sure what the

Inline summary for void process_fun_at(const Fun&, T) [with Fun = float(float);
T = float]/2 inlinable
...
    size:0.000000, time:0.000000, predicate:(true)
    size:3.000000, time:2.000000, predicate:(not inlined)

lines mean.  Honza?

[Bug tree-optimization/51680] [4.7 Regression] g++ 4.7 fails to inline trivial template stuff

[hubicka at gcc dot gnu.org]

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

--- Comment #11 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-01-07 16:11:50 UTC ---
Well, the problem here is that we compile with -O2 and function is not declared
inline. Conequetely GCC inlines only when it thinks code size will shrink. 
Inliner always works one step at a time and it does not know that inlining
process_fun_at is important to inline to inline add.

We now have estimate_edge_devirt_benefit that I fixed last week to also notice
indirect calls like this one.  Unfortunately it is still not enough, since
inliner won't get past the idea that replacing a call by two calls is
increasing code size.

For 4.8 I plan to include logic that allows to bypass the limits when inlining
is known to be profitable, but I don't see much to do in 4.7 timeframe. 4.6
early inlined it more due to accounting bug.

Honza

[Bug tree-optimization/51680] [4.7 Regression] g++ 4.7 fails to inline trivial template stuff

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |hubicka at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #12 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-01-07 17:30:24 UTC ---
Well, on second thought, we already have logic for -Os and cold calls that
COMDAT functions are unlikely to be shared across compilation units. There is
nothing that prevents us from enabling this also for -O2.  Additionally Maxim's
code has thinko in it disabling itself for indirect calls in many cases.

Obviously this will still break when process_fun_at will be called more than
one in the unit. But that is for 4.8.

I am testing patch.

[Bug tree-optimization/51680] [4.7 Regression] g++ 4.7 fails to inline trivial template stuff

[hubicka at gcc dot gnu.org]

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

--- Comment #13 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-01-07 23:35:13 UTC ---
Author: hubicka
Date: Sat Jan  7 23:35:08 2012
New Revision: 182983

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182983
Log:

    PR tree-optimization/51680
    * ipa-inline.c (want_inline_small_function_p): Be more lax on functions
    whose inlining reduce unit size.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ipa-inline.c

[Bug tree-optimization/51680] [4.7 Regression] g++ 4.7 fails to inline trivial template stuff

[hubicka at gcc dot gnu.org]

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

--- Comment #14 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-01-08 16:39:08 UTC ---
Author: hubicka
Date: Sun Jan  8 16:39:00 2012
New Revision: 182995

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182995
Log:

    PR tree-optimize/51680
    * ipa-inline-analyss.c (evaluate_properties_for_edge): Fix conditoin on
when
    known_vals needs to be computed; cleanup.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ipa-inline-analysis.c

[Bug tree-optimization/51680] g++ 4.7 fails to inline trivial template stuff

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.0                       |4.8.0
            Summary|[4.7 Regression] g++ 4.7    |g++ 4.7 fails to inline
                   |fails to inline trivial     |trivial template stuff
                   |template stuff              |
           Severity|normal                      |enhancement

--- Comment #15 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-01-08 16:42:58 UTC ---
We no longer regress here.  I would like to keep this open tas a reminder that
for 4.8 we should do better (i.e. inline process_at even when it is called many
times).

Honza

[Bug tree-optimization/51680] g++ 4.7 fails to inline trivial template stuff

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-09 09:58:52 UTC ---
This should not be fixed in the early inliner at all.

[Bug tree-optimization/51680] g++ 4.7 fails to inline trivial template stuff

[hubicka at ucw dot cz]

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

--- Comment #17 from Jan Hubicka <hubicka at ucw dot cz> 2012-01-09 15:18:43 UTC ---
> This should not be fixed in the early inliner at all.
Well, it is not (just to summarize the disucssion on ML). The change is into
IPA inliner.

Honza

[Bug tree-optimization/51680] g++ 4.7 fails to inline trivial template stuff

[miles at gnu dot org]

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

--- Comment #18 from miles at gnu dot org 2013-01-09 05:35:35 UTC ---
Is this considered fixed yet?  Given the following example, the latest Debian
trunk snapshot ("4.8.0 20121120 (experimental) [trunk revision 193662]", using
flags "-O2") seems to do a good job inlining this code well, even with many
calls (whereas 4.7 does not, once the number of calls goes beyond 3-4 or so):

    extern void process (float);                                                
    template<typename Fun, typename T>
    void process_fun_at (const Fun &fun, T x)
    {
      process (fun (x));
    }
    static float add1 (float x)
    {
      return x + 1;
    }
    void test0 (float i) { process_fun_at (add1, i); }                          
    void test1 (float i) { process_fun_at (add1, i); }
    void test2 (float i) { process_fun_at (add1, i); }
    void test3 (float i) { process_fun_at (add1, i); }
    void test4 (float i) { process_fun_at (add1, i); }
    void test5 (float i) { process_fun_at (add1, i); }
    void test6 (float i) { process_fun_at (add1, i); }
    void test7 (float i) { process_fun_at (add1, i); }
    void test8 (float i) { process_fun_at (add1, i); }
    void test9 (float i) { process_fun_at (add1, i); }
    void test10 (float i) { process_fun_at (add1, i); }
    void test11 (float i) { process_fun_at (add1, i); }
    void test12 (float i) { process_fun_at (add1, i); }
    void test13 (float i) { process_fun_at (add1, i); }
    void test14 (float i) { process_fun_at (add1, i); }
    void test15 (float i) { process_fun_at (add1, i); }
    void test16 (float i) { process_fun_at (add1, i); }
    void test17 (float i) { process_fun_at (add1, i); }
    void test18 (float i) { process_fun_at (add1, i); }
    void test19 (float i) { process_fun_at (add1, i); }

[Bug tree-optimization/51680] g++ 4.7 fails to inline trivial template stuff

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.0                       |4.8.1

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-22 14:45:23 UTC ---
GCC 4.8.0 is being released, adjusting target milestone.

[Bug tree-optimization/51680] g++ 4.7 fails to inline trivial template stuff

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.1                       |4.8.2

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.1 has been released.

[Bug tree-optimization/51680] g++ 4.7 fails to inline trivial template stuff

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.2                       |4.8.3

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.2 has been released.

[Bug tree-optimization/51680] g++ 4.7 fails to inline trivial template stuff

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.3                       |---