Hi, > I think my worry would be all the targets that support tail calls, but > which we can't easily test. ie, we put in the hack, but when do we > know it can be removed?
Well it would be easy to make a runnable torture test. I'm not sure how easy it would be to do it using a scan-assembler test given the stack pointer adjustment may not use a standard pattern (and the SP has many different names). > Is there any property of the code that we can look at instead of a hack > like this? We could simpify __builtin_eh_return and implement it as a libgcc function or automatically generated thunk. Basically all you need is tailcall a 2-instruction helper which adjusts the stack and then jumps to the given function pointer. This way you don't need the complex special cases and optimization disables for eh_return functions. Or drop support for eh_return altogether since its one and only use seems to be for unwinding (which already requires target specific code). Wilco
