On 5/13/19 4:51 PM, Jakub Jelinek wrote: > On Mon, May 13, 2019 at 04:29:21PM -0600, Jeff Law wrote: >>> 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. > > The problem as has been said in this thread is that crtl->calls_eh_return > flag is only set during expansion, so if it is tested when deciding if we > should allow the tail call or not, it might be (and in the case of > _Unwind_Resume_or_Rethrow it is) too late, because we first expand the call > that could be tail call and only afterwards expand the __builtin_eh_return > and set crtl->calls_eh_return. > > In https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00484.html I've posted a > patch that would set it earlier (or it could be set during gimplification > and propagated during inlining, would need to be in cfun->calls_eh_return > instead of crtl->calls_eh_return) and then targets for which we do not want > to bother with it or where it is not beneficial to have tail calls in > functions that call __builtin_eh_return (as I said in the thread, e.g. on > x86_64-linux it is both smaller and faster), the targets which we expect to > fail currently or even have a proof of that can just punt. I would go with a patch that got the info set earlier and just punt in the generic code. I just don't see this case as terribly important to optimize.
jeff
