Re: IRA plans and latest version of IRA patch

[Andi Kleen <andi at firstfloor dot org>]

> Yes, that is an interesting idea.  But again, IP IRA should see the body
> of the function (what registers were used in the function and indirectly
> called functions).  If it does not see the body (because it is in
> another file or even worse is a library function), IP RA could do
> nothing.  If it sees the body and the function is small, the compiler
> will inline the function.  If it sees the body and the body is large,
> the most probably the body will use all callee-clobbered registers and
> again IP IRA can do nothing.

The special case of "very infrequent call" doesn't really require seeing
the body. It's enough to know the call is very infrequent and to just
have a small stub somewhere that saves all callee saved registers and
then calls the function. This stub could be managed like C++ vtable
stubs, as in always generate and letting the linker sort out duplicates.

> Also, imho it is better put save/restore code in the caller than in
> callee because in the caller the code could be moved to less frequent
> points.

For the special case of very infrequent functions (error handling)
it doesn't really matter because the call is always infrequent. Only
the impact on the caller matters.

Putting the stub into the caller would work too, but right now gcc
seems to usually impact the register allocator of the whole function
instead of just saving/restoring around the call [I have not checked if
IRA does that better] Also it would generate larger code of course.

I suspect this could be all actually done outside the register allocator
in a separate pass, but that would be kind of very special purpose.

-Andi