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

Op di 29-07-2003, om 15:05 schreef Gabriel Dos Reis:
> | No, I've shown that inline still has a meaning in GCC whereas you
> | claimed that "it was decided that the compiler knows better than the
> | programmer", i.e. the compiler overrules the user.
> And what I claimed corresponds to reality.  See

You're just pointing to a mail that shows that warnings appeared after
the fix for PR10180 and half a dozen duplicates went in (the first
report being almost as old as the hard-coded limits in tree-inline.c,
still cp/optimize.c back then).  Just because a warning switch has been
broken for two years does not mean that someone suddenly decided that
the compiler is smarter than us.  You would have noticed those warnings
way earlier if that warning had been fixed earlier.

> for *facts* from mainline.  The compiler has decided it can ignore
> inline when its counting of something has reached some limits, i.e. he
> knows better than the programmer.

Ah, well, then I take it you're now objecting to both the tree and rtl
inliners :-)  Did you know the RTL inliner also has inlining limits? 
And that icc has inlining limits?

AFAICT, the tree inliner has had limits since March 27, 2001, see

*That* is a fact.

So if everyone has such limits, one might assume you need them to make
proper compilation possible.  It's a trade-off that you have to make:
amount of inlining vs. {code size, memory footprint, compiler
performance, etc}.  For C++ this may sometimes mean an abstraction
penalty (which we hope to minimize with the tree optimizers, right?),
but in most cases it works just fine.

So what are you suggesting?  Are you saying that inlining limits are
there for _no_ good reason, are you going to claim that "inline" should
just mean "inline no matter what"?  Then before you know it you have
them complaining about how slow GCC is blahblahblah.

Now, the one point you do have is that the limit is arbitrary and in
fact until recently the limits really made no sense at all.  But with
the new function body size estimates Jan implemented recently, we're
already doing a much better job, and there is still room for
improvements.  Take a look at that and try to improve it.  _That_ would
be helpful.

> |  What I've shown is that the compiler can take a hint.
> No, you've shown that on a branch development, the compiler appears to
> give "inline" its obvious meaning.

BS.  The trunk does exactly the same thing, it's still the same tree
inliner.  You should have tried it before you made this absurd


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