This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Fix PR19401: always completely peel loops
On Thu, 14 Jan 2005, Gabriel Dos Reis wrote:
Daniel Berlin <firstname.lastname@example.org> writes:
| On Thu, 14 Jan 2005, Gabriel Dos Reis wrote:
| > Andrew Pinski <email@example.com> writes:
| > | On Jan 13, 2005, at 6:09 PM, Gabriel Dos Reis wrote:
| > | > I disagree. Optimizations should support language usages/patterns and
| > | > language idioms. Not all languages have the same idioms or usage
| > | > patterns. There are optimizations that can benefits to set of
| > | > languages; but not all of them fall into that observation.
| > | > We've been through this many times.
| > |
| > | Yes they might use different idioms but most of the time the
| > | optimizations don't do anything for the languages which use
| > | that feature so it should not matter to them. Anything which turns
| > You left out your statement I was objecting to:
| > No optimization
| > should be dependent on what front-end you used.
| He's right.
And I disagree. Last time, that language-independent optimization
argument came up, it was about "inlining". Obviously Ada people had
different expections from C people who had different expcetions from
C++ people. Trying to use one-size-fits-all is one the sneaky
weakness of GCC insfrastructure.
Then it's a sneaky weakness of IBM's entire compiler family, which has a
completely language independent middle end and backend, for example.
And they do *all* of the optimizations.
It doesn't do anything different in the middle-end, or the backend because
you've given it C++.
In fact, only the debug info generator even *notices* it's C++ that
generated the intermediate code.
I'm sorry Gaby, but C++ just isn't magically different.
What it takes to run code fast is dependent on the intermediate form you
have in hand, *not* what generated it.
If you really believe C++ "just needs different optimizations" because
it's C++, then i'll just give up now instead of continuing this
To take your example, btw, Inlining *is* something that is a language
Just because we don't have the right heuristics compared to other
compilers (we inline less than we should in some cases, because our data
structures are so large that inlining too much takes too long and too much memory to
compile, in other cases, the heuristics are just wrong).
Of course, there is some point where inlining stops helping due
to code growth, etc, but these are *not* language dependent factors.
The bottom line is that if the program isn't running fast because the
inliner didn't inline something, the inliner is making a bad decision for
that intermediate code.
It doesn't matter if you wrote this original program in C, C++, Ada,
Java, or Objective C. You could make the same
intermediate form be generated in some other language, and the problem
would still exist. Any attempt to fix this by fudging frontend limits is
simply a hack, pure and simple.
We also used to use inlining to make up for our lack of any
interprocedural analysis, and to some degree, our lack of global
optimization. The global optimization part is less true nowadays.