Messages in this thread | | | Date | Thu, 27 Feb 1997 13:34:43 +0100 (MET) | From | Bernd Schmidt <> | Subject | Re: a.out binaries that are 66% faster than ELF, problem found? |
| |
> i think we have the answer, as the same problem is causing unjustified > stack overflows in the kernel. GCC is allocating lots of stack slots to > pseudoregisters (correct me if i'm saying something stupid), and the > optimization process removes 90% of them.
No, it allocates pseudoregisters for variables (unless they are volatile or their address is taken) and if it can't get hard regs for them it allocates stack slots during reload.
> But GCC doesnt 'compress' the stack after that.
> for example, aic7xxx_isr() has a real stack usage of 53 bytes,
There aren't only the variables at the start of the function. Look a bit further down, somewhere in a local block they allocate a huge array. That's where the stack usage comes from (yes, I looked at this too yesterday for a different reason - frightens me because I happen to have a 2940).
BTW, it occurred to me that compiling the kernel with -finline-functions _may_ increase the probability of kernel stack overflows - say you have a function which may get called recursively, and which (rarely) calls another small function that uses lots of stack. If GCC were to inline the small function, you'd have a much higher stack usage in the normal case.
> 2.5.8 2.7.2.1 > RC5_KEY_CHECK: RC5_KEY_CHECK: > subl $12,%esp subl $304,%esp
Now that _is_ interesting.
[snip - more interesting stuff deleted]
> For the 'sparse stack problem' i dont know how hard it is to fix this in > GCC, my feeling is that all the abstractions are already there to 'remap' > stack slots, if yes then the fix should be easy. I'd sure play around with > a few PGCC snapshots if such optimization would be implemented ;)
I guess you could implement something like this in PGCC, but I doubt you'd get it into the "normal" gcc. There are apparently machines which can't handle arbitrary offsets to sp/fp, which means that once register allocation is complete (and only at that point do you know which stack slots you are using), you can't safely change the offsets. I could be wrong, though.
Bernd
| |