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: [RFC] Fix PR19401: always completely peel loops

On Thu, 14 Jan 2005, Gabriel Dos Reis wrote:

Daniel Berlin <> writes:

| On Thu, 14 Jan 2005, Gabriel Dos Reis wrote:
| > Andrew Pinski <> 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 discussion.

To take your example, btw, Inlining *is* something that is a language independent optimization.
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.

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