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

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

No, i'm not talking about something different, unless you are expressing
yourself badly.

You seem to be saying:
The inliner has parameters and factors and heuristics it uses to do it's
job, such as max growth in a function, cost of the call, etc.
It uses these to determine what to inline.
These parameters differ between languages
Therefore, the language front end should be able to diddle the
parameters, because it will get better results.

I'm saying this is wrong because it assumes that

1. Either the heuristics, factors, and parameters it is using to
determine which functions to inline are currently correct in the first
place, and thus, it must simply be the numbers it is using in
instantiations of these factors, heuristics, and parameters that are
different for your language.


2. Inlining parameters depend on language, instead of what the
intermediate code looks like

Neither of these premises is correct.

2. Is provably false because you can almost always get some other
language to generate the exact same intermediate code.

1. is just a retelling of the symptom, which is "our inliner doesn't do
as good a job on C++ code as it does on C, because it's not inlining
enough".  The fact that it's not inlining enough doesn't mean the
numbers should be changed because it's C++.  It means the heuristics are
probably wrong, or we are missing factors, or the numbers are wrong for
*all* languages.

This is because inlining is a language independent optimation, and thus,
if the numbers you need to plug into your inliner to get good
performance change with each *language* you throw at it, there's
something wrong with your inlining algorithm in the first place.

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