Re: std::pow implementation

[Richard Earnshaw <rearnsha at arm dot com>]

> On Wed, 30 Jul 2003, Gabriel Dos Reis wrote:
> 
> > Firstly, I do not trust you that counting lines is sensical mesure for
> > inlining.  Secondly, it is up to the programmer to decide whether he
> > wants the 2000 lines in the middle his class.  Whether it is stupid
> > depends on what he is doing and *you* have no cluie to know that.
> >
> > Do trust the programmer.
> 
> As a gcc user, I would just like to say, that it would be nice, if there
> is some kind of ``wrong inline'' warning which might teach programmers
> about what compiler thinks about inline - of course compiler should honour
> inline even in the case of wrong usage... The programmer is responsible
> for removing it in this case...
> 

The problem here is that there is no clear point at which a  "right" 
inline becomes a "wrong" inline.  Sometimes it may be right and sometimes 
not.  It depends on many things, such as the optimization goals, the 
processor in question, the context of use, etc, etc.

For example, consider this case:

class foo{
  int _a;
public:
  void f (int a, int b)
		{
		  if (a != 1) {
		    // 100 lines of complex code
	          } else
		    _a = b;
	        }

};

Now clearly, if a is the constant literal 1, it's good to inline this, 
since it collapses to a single assignment.  If a is not one, then the case 
for doing so is much less compelling.  The benefits of doing so are far 
less clear (indeed, better code might result on some processors if the 
code is not inlined, because of register pressure etc).  Even if the code 
is not inlined, the compiler might still be able to use the definition to 
improve the way CSE is done, for example, since now the compiler can see 
what sub-expressions might be killed by the function call.

Now, assume that the amount of code in the a!=1 case is reduced.  At what 
point does it become beneficial to always inline?  Can the programmer 
tell?  Should he write the code in a separate function, or should he leave 
it to the compiler to decide?  What happens if the code is ported to 
another machine with twice as many registers?

With Gaby's suggested interpretation, the compiler has *no* choice; it 
must obey the inlining constraint because the programmer always knows 
better...  Even when prepared to admit that he doesn't.

R.