At least as far as I have been able to find, there's no mention of these anywhere in any version of the internals manual.
I think they should at least be mentioned and the similarities/differences to ordinary call/call_value/call_pop/call_value_pop explained, because they actually turn out to be vital, but the dependency isn't immediately obvious: if you implement epilogue and sibcall_epilogue (as schedulable RTL generated by expanders, rather than as insn patterns with code-generating functions which just opencode the epilogue at assembly-generation time), and you haven't implemented sibcall/sibcall_value patterns, the compiler falls back to the ordinary call/call_value pattern and then you get that abort in propagate_one_insn when it finds itself trying to delete an epilogue insn. I initially thought it would be sufficient to just test for SIBLING_CALL_P (insn) in the code generation for the call/call_XXX patterns, but it turns out to be subtly not so. This may be only apply on architectures that have a link register for all I know. It seems at first glance to have been because of using an ordinary call pattern (which clobbers LR) to match a sibcall (which does not, in fact, use LR at all); it was the reload of the LR from the stack prior to the sibcall jump that got deleted, but then again it was only a simple testcase from the testsuite and there weren't any other items on the stack frame in that instance, so I can't be sure. Since I have only deduced the existence of these patterns from stumbling across HAVE_sibcall etc. in calls.c, I won't immediately volunteer to write the doco patch. Shall I file a bugzilla, or is there some documentation about the sibcall patterns somewhere that I missed? cheers, DaveK -- Can't think of a witty .sigline today....