std::pow implementation

Steven Bosscher s.bosscher@student.tudelft.nl
Wed Jul 30 16:09:00 GMT 2003


Op wo 30-07-2003, om 17:43 schreef Gabriel Dos Reis:
> Steven Bosscher <s.bosscher@student.tudelft.nl> writes:
> | Richard Guenther's experience with this meaning for "inline" are not
> | that positive: http://gcc.gnu.org/ml/gcc/2003-07/msg02140.html.
> 
> It is no surprise that inlinig with no proper constant propagation and
> dead code elimination does not produce better code.

Absolutely true.  See the example I posted yesterday from tree-ssa, you
can actually see it shrink from lots and lots of code to a trivial
function (and as a bonus it should also cut compile time because in
Richard's example, expand was a bottleneck, and we get rid of code
before expanding with tree-ssa)

But I think any properly optimizing compiler would be able to cut
functions down a lot after inlining.  The art is deciding what to inline
before you know how much of the inlined code will die after
optimizations.  That is what this discussion should be about...

> In effect, if you have a close look at the pattern of usage of C++,
> you'll notice that after inlining, there are lots of opportunities for
> the compiler to remove junks.  KCC understood that.

The question is, how did it know in advance what would turn into junk
and what would not.  That's the key.

> 
> | And then he's the guy who always wants more inlining :-p
> 
> He does not want (rightly) "just" wants more inlining.
> 
> It helps just not to focuse on the medium, the message is more
> important. 

Note the f*cking smiley.  I hope you'll develop a sense of humor some
day.

Gr.
Steven



More information about the Gcc mailing list