https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894
--- Comment #5 from Peter Bergner <bergner at gcc dot gnu.org> --- (In reply to Alan Modra from comment #4) > Do check that the result is not a direct call. I think I was wrong to say > the assert could be removed (or modified as you have done). I'm assuming you mean check that we DO have a direct call. When we talked offline, you said you were worried about what happens when we use -mlongcall with this test csae. When I use that option, we never end up calling rs6000_sibcall_aix(), so that option basically disables sibling calls altogether. I believe if we call rs6000_sibcall_aix(), we know we have a direct call that is also a valid sibling call and the assert is just confirming that. Before pcrel, valid sibling calls required the caller and callee to have the same TOC value (which is what that assert was verifying) because the TOC restore is done in the caller and not the callee and if we do a sibling call, we'll skip the TOC restore in the caller, which only works if the callee has the same TOC value. Now with pcrel, the caller doesn't use r2 as a TOC pointer at all and doesn't expect or need it to be restored. Additionally, callers to a pcrel function don't expect r2 to be preserved either. This allows pcrel callers to sibling call callees we couldn't before, so I think we do just want to relax the assert to verify we have the same TOC value only when the caller is not pcrel. Given we only call rs6000_sibcall_aix() with direct calls that are valid for sibling calls, do you agree my patch above is ok or do you see some other issue I'm not thinking of?
