> On Sunday 31 December 2006 00:59, Jan Hubicka wrote: > > > Also I should mention, this also fixes a possible bug with libcalls that > > > are embedded in one another. Before we were just assuming if we have a > > > REG_RETVAL, then the previous REG_LIBCALL would be the start of the > > > libcall but that would be incorrect with embedded libcalls. > > > > We should not have nested libcalls at all. One level of libcalls is > > painful enough and we take care to not do this. > > It's unclear whether we can have nested libcalls or not. We expect them > in some places (especially, see libcall_stack in gcse.c:local_cprop_pass) > but are bound to fail miserably in others. > > This is something I've been wondering for a while. Maybe someone can > give a definitive answer: Can libcalls be nested, or not?
My understanding is that libcall should not be nested and there is code to avoid nesting in emit_libcall_block. I believe this was also outcome of some disucssions with Rth while back. Historically some code was written to support nested libcalls but I believe it was never useful but it got propagated to new code. If we care, we probably could tweek verify_flow_info to verify that libcalls are unnested and don't span BB boundary, but I have too many other verifier related plans right now to be able to promise to get into this soon. Honza > > Gr. > Steven
