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/
