On Tue, May 21, 2024 at 3:35 PM Andi Kleen <a...@linux.intel.com> wrote: > > > I can't see how this triggers on the IL above, the loop should have > > ignored both the return and the clobber and when recursing to > > the predecessor stop before the above check when runnig into the > > call? > > Yes, I tracked that down later. The problem was that there > were multiple successors to the BB due to exception handling, > which makes the find_tail_calls walker give up. > > Putting the new pass after ehcleanup fixed that, but there > are still cases when ehcleanup cannot get rid of them and > then it gives up. musttail checking at expand time still > works, but can only give a vague error message. > > > > > > In a optimized build this passes, but with -O0 it always fails > > > when the pass is placed before pass_optimizations_g. I assume > > > it's some problem with mem ssa form. > > > > > > Any ideas how to fix that? Otherwise I can restrict musttail to non > > > structs. > > > > I wonder how this works when optimizing? > > It just doesn't. You need optimization to do tail calls with > structs. The only alternative would be to detect the situation > and pull in some extra passes. > > Also even with optimization it only works for structs that > fit into registers. This could be maybe fixed, but is out of scope > for this patch kit.
I see. I do wonder how we should deal with the inherent dependence on optimization for [[musttail]] to work then? "Solve" the problem with good documentation? Offer a -fignore-musttail option to allow a -O0 build to at least succeed? But then [[musttail]] would rather be [[shouldtail]] and can no longer be for correctness? How does clang solve this? Richard. > > -Andi
