On Fri, Dec 10, 2021 at 03:40:30PM -0700, Jeff Law wrote: > On 12/9/2021 6:06 PM, Marc Feeley wrote: > > In any case, as I said previously, I don’t want to check if gcc did > > not optimize the tail calls… it is too late to do anything other than > > essentially tell the programmer “sorry I couldn’t compile that > > program correctly”. > We don't generally like that kind of diagnostic particularly from the > code generator. If it's valid C code, then we need to generate correct > target code. Yes. But we *do* have sorry()s for some other cases where it is in principle possible to generate correct code, but we just don't have that implemented. > >So what I need is some way to test at compile time if for the target > >architecture and compile options there is a guarantee that tail calls will > >be optimized (if the C code obeys the usual set of constraints). > >Something like > > > > #if __has_attribute(tail_call_supported_on_this_architecture) > > /* use tail calls for jumping around... */ > > #else > > /* use trampoline fallback... */ > > #endif > Which is the fundamental problem. GCC simply doesn't have the concept > that "this must be implemented as a tail call". All architecture support tail calls, and all architectures do not support them everywhere: for some code GCC will not do a tail call on any architecture. An attribute that means "sorry() if you cannot do a tail call here" (or "on any call to this function") can be implemented, and will work fine in practice for all users, in my estimation. > You might want to touch base with Iain Sandoe though. I vaguely > remember this coming up in the context of coroutines. Yes, it did. I don't remember the exact considerations there. It is done from GCC itself, so it has more introspection than if it would be done from user code. Not sure if that matters for the actual implementation though? Segher
