Steve Gehlbach steve@nexpath.com writes:
Eric W. Biederman wrote:
Steve for a feel of my worries try compiling that code with gcc-3.3. If what I saw earlier today is right it won't work because someone has decided that aggressive inlining is bad thing...
Hmm... I assume you mean gcc-3.2.2 unless you have a pre-release.
I don't currently have a pre release but that is what I was thinking about. But 3.3 is scheduled to release in the next couple of weeks. And one of the issues that was being vigorously discussed on the gcc list was how to handle the fact that 3.3 does not inline nearly as much as 3.2 and there was not currently a way to get it to inline more than it thought was reasonable. was
on a RH machine, it seems to work on my code, although I had to delete a couple of asm's and fiddle with raminit.c: went back to "register int i asm ("ecx");". Otherwise gcc3.2 was more efficient (-181 lines), and it uses the %ebp differently. As a result, checking for "push" or "esp" is not effective to determine spill cases, you have to look for %ebp which it does tmp storage with mov's.
The requirements of these small tweaks when building are why I am convinced that in the long run we need actual compiler support. Either in gcc or in one we write ourselves. For now we have an easier way to generate the assembly code.
Interesting that gcc3.2 seems to ignore the -fomit-frame-pointer since there is a "leave" at the end. Not sure why.
Note the reason for the push of the %ebp in gcc2.95 is that 2.95 uses it for temp storage (hadn't noticed this before) if you set -fomit-frame-pointer, and so it push/pops it on entry and leaving.
That makes sense.
Eric