This is the mail archive of the gcc@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]

Re: std::pow implementation


dewar@gnat.com (Robert Dewar) writes:

| > Defining a function inline is not a careless action.  If inlining
| > isn't profitable, the programmer will profile et remove the inline
| > definition.  You don't know better than the programmer.
| 
| This is often incorrect, because often code is written to be portable, and

In which ways are you seeing portability here -- apart from the lock-in
syntax __attribute__((__always_inline__))?

The meaning of "inline" here is for C++, not for all languages
supported by GCC.

Programming in C++, especially using its standard library or libraries
using STL-like style -- which happens more often than you might
imagine --  relies on inlining.

| the decision on what is profitable to inline is target dependent. Furthermore
| deciding whether something is profitable to inline on a given target requires
| detailed knowledge of the target architecture, knowledge that very few 
| programmers have these days.

But the fact is that the compiler is not doing better by going its own
programmed logic.  We've not reached the same level of sophistication
as for register allocation.

-- Gaby


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