Re: [RFC] Fix PR19401: always completely peel loops

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Daniel Berlin <dberlin@dberlin.org> writes:

| On Thu, 14 Jan 2005, Gabriel Dos Reis wrote:
| 
| > Daniel Berlin <dberlin@dberlin.org> writes:
| >
| > | On Thu, 14 Jan 2005, Gabriel Dos Reis wrote:
| > |
| > | > Andrew Pinski <pinskia@physics.uc.edu> 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++.

I think you're talking about somethign different.  The abstract
implementation of inlining for example, is largely language-indepent.
However, the actual parameters used to instantiate that abstract
implementation to give a useful inliner that support language usage
and patterns do depend onn the languages.  If you look through the
archives, you'll see that was the base of disagreements when we
discussed inlniing for example.

| 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.

I missed the entire point.  

-- Gaby