[LLVMdev] calling conventions and inlining

[Chris Lattner]

On Sun, 8 May 2005, Markus F.X.J. Oberhumer wrote:
> Chris Lattner wrote:
>> On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote:

>>> but looking at the disassembly suggests that this might mainly be an issue 
>>> of x86 codegen, which is rather young as compared to other compilers.
>> If you're testing on X86, I would be strongly suspious of the X86 backend, 
> I'll try to come up with some simple X86 example that shows some problems. I 
> haven't looked at the PPC code, though.

My experience with performance optimization has shown me that you 
shouldn't make assumptions, even based on extensive experience.  The only 
way to track down performance issues is to be analytical and thorough.  I 
look forward to your example.

>> You've just ignored all of the reasons I gave you above about why this is a 
>> bad idea.
>
> Well, that's probably because I have to care for fast code, while you care 
> for a compiler framework that produces fast code. Unfortunatly these 
> sometimes are quite different goals ;-)

See above.  Speculating that the inliner is the cause of all of the 
problems does not seem either analytical or thorough, regardless of goals.

>> Before pointing the finger at the inliner, it would be good to understand 
>> what is going on in the testcase.  Can you share or reduce the problem to a 
>> small testcase?
>
> Put simply, the inliner is too greedy and nice little leaf functions suddenly 
> run out of CPU registers. Even gcc 3.4 with -funit-at-a-time started inlining 
> too much, but at least I can tell gcc where to stop. This whole noinline 
> issue may be somewhat X86 specific, though.

I can believe that this is an issue, but (as Alkis pointed out) this is a 
deficiency in the *register allocator* not the inliner.  The problem 
should be fixed there.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/