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.
Jakub
