This is the mail archive of the
mailing list for the GCC project.
Re: std::pow implementation
- From: Theodore Papadopoulo <Theodore dot Papadopoulo at sophia dot inria dot fr>
- To: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Cc: Martin Reinecke <martin at MPA-Garching dot MPG dot DE>, gcc at gcc dot gnu dot org
- Date: Mon, 04 Aug 2003 15:51:35 +0200
- Subject: Re: std::pow implementation
> listing the (new) standard library in this discussion will create more
> confusion than helps sort out the issue.
That was not my point, I listed some of the big (necessary and/or good) changes
in the C++ context. The bigger library was often associated with bigger compile times,
but as I said the list is certainly not changes that have to be
accused for the compile times.
> | So saying that KCC was better than gcc because it inlined more was
> | simply not true (at the time where this story begins), KCC was still
> | often better than gcc and gcc was inlining everything it could (ie
> | marked as inline either explicit or implicit).
> Please do be careful in your rephrasing. I'm specifically concerned
> about honouring the inline request and -not- "inlining more". And I'm
> not saying GCC should inline everything. Part of the confusion in
> this debate came from the fact that people are considering that
> honouring the inline request means inlining everything.
Agreed. But, at that time gcc was "honouring the inline request" even
better than KCC was. That is what the more refers to... When I say
that gcc inlined everything it could means that it was "honouring the
inline request in all places where it could".
> | - The inlining strategy plays some important role. In the function
> Equally important is considering the language-specific semantics.
Totally agreeing. I think, I basically say the same things somewhere
else in the text.
> | Final point: it has been reported here (and it is also my |
> experience), that for some C++ code, sometimes -Os (which I believe |
> restricts the amount of inlining) results with more efficient code |
> than all over -O choices.
> You seem to be confusing "inline" with "optimize".
Well, I agree that the example is not as clear as I would have wished...
Certainly -Os has consequences on the inlining limits but I agree
this might be drawn in many other program transformations.
> I'll send in a moment a text I intended to send some time ago.
I'll read it.
Note that my point was not to discuss how inline should be honoured.
I gave just many contradicting facts:
- when gcc honored inline like you would like it did, it worked and
was faster than it is now (not sure about the compiled code speed but
it was not that bad in my recollections).
- Some limits on the "honoring" just have to exist.
- on the other hand, as mentioned elsewhere in the thread, just
saying that the programmer knows what it does is simply not quite
true... And the portability makes things even worse.
My guess (but this is just that) is that the situtation is bad for
- inlining is now tree-based but most other optimizations are
- general speed has decreased (at least up to recently).
- most inlining limits were set based on too narrow testing (I
believe it was mostly C programs). I agree that C and C++ need
Now if I have to say something abou the topic, I believe that,
unfortunately, because of the compilation times, I not quite sure that gcc is
ready for the old "honor mostly every inline up to some extremely
high limit"... that is why I said that the current situation is just
a pragmatic move rather than a definitive answer.
As you said, to really realize the full benefits of inlining, one has
to embed somehow inlining with other optimizations (cprop, dce, ...),
currently (correct me if I'm wrong), the situation is doomed because
inlining decisions are made on trees and most of these optimisations
come later on RTL so that the metrics used to decide if inlining is
a profitable choice cannot take account of the further optimizations
the inlining may allow. As I said my hope is that the SSA stuff will
change the overall picture and will made the "compiler made"
decisions a better alternative than it is now. Will the code size
decrease (and hopefully the memory consumption and speed) be enough to
"honour" all inline hints as you argue (provided it is better than
the choices made by the compiler) I do not know.
My main conclusion is that inlining limits are just a trick to make
the compiler fast enough to convince people to use it. They must be
reconsidered regularly and IMHO made specific to each language (to
better cope with the language expectations).
This is unfortunate and just a pragmatic conclusion and I place my
hopes in SSA for a better answer to the problem.
Please correct me if I'm wrong in my expectations !!!
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01