------- Comment #15 from jakub at gcc dot gnu dot org 2008-04-10 17:40 ------- The i?86 Linux kernel just got bitten by this again, see https://bugzilla.redhat.com/show_bug.cgi?id=427707 In this case, it wasn't about a tail call, but I believe high register pressure that caused modification of the incoming stack slot, which is undesirable for kernel asmlinkage functions.
The #c14 patch after small fixup (s/preserve-stack/preserve_stack/) fixes some cases, but certainly all, on the other side pessimizes code even where it is not strictly necessary (though it is unclear how hard would it be to improve that). On f1 already vanilla gcc doesn't modify the incoming stack area, and the patch just pessimizes it by reading all arguments into registers and then storing them into a different stack slot, eventhough d argument is actually never modified and so could be used directly from the stack slot, avoiding one move from memory and one move to memory. f2 is an example where the patch doesn't help at all, and incoming stack area is modified even with the patch. On f3 the patch properly prevents doing tail call, as that would actually modify the incoming stack area. But on f4 there is no need to avoid the tail call. I guess we could live with avoiding all tail calls, but a) need a fix for f2 b) for f1 I'd say at expand time for -O1+ we should know whether an argument is TREE_ADDRESSABLE or not, and whether it is ever modified or not, which could help us avoid unnecessary copying. Still will need to make sure reloading won't push anything into the incoming registers area. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27234
