On 5/13/19 2:09 PM, Jakub Jelinek wrote: > On Mon, May 13, 2019 at 07:57:30PM +0000, Wilco Dijkstra wrote: >> 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. > > That is a serious misunderstanding of what __builtin_eh_return does. > For the most part, __builtin_eh_return works by forcing all call clobbered > registers to stack, having that described in the unwind info and having the > unwinding code modify that saved info when needed. The adjustment of the > stack is done only on approx. half of the targets where the destination > stack pointer should be derived from CFA instead of being restored with the > rest of the call saved registers. You can't do this in assembly, it needs > to be done in the same function that saves the state etc. So why not just reject tail calls when we see __builtin_eh_return. It's not ideal, but that feels better than the currently posted hack.
jeff
