From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fergus Henderson To: Richard Henderson Cc: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: forcing tail/sibling call optimization Date: Wed, 03 Jan 2001 15:53:00 -0000 Message-id: <20010104105314.A30758@hg.cs.mu.oz.au> References: <20001201185846.A12462@hg.cs.mu.oz.au> <200012012350.PAA08096@racerx.synopsys.com> <20010104072414.B7732@hg.cs.mu.oz.au> <20010103130916.C15036@redhat.com> <20010104095831.A23010@hg.cs.mu.oz.au> <20010103153251.A18256@redhat.com> X-SW-Source: 2001-01/msg00149.html On 03-Jan-2001, Richard Henderson wrote: > Mostly what I meant here is "Does CALL_EXPR_TAILCALL imply tail-ness"? I think the answer to that should be yes. > CALL_EXPR_TAILCALL. OK. > if the front end didn't really care if the tail > call didn't happen, it could query the target before setting the bit. How can it query the target? The query needed is not just "does this target support tail calls", it is "does this target support *this* tail call", and the answer can depend on lots of stuff that the front end doesn't want to know about. > Let's just go with the one bit for now and make it mean "require". I don't think that will work. The "require" bit is pretty useless until GCC supports tail calls consistently, because AFAICT the front-end can't safely set it, at least not without encoding too much knowledge of the target and of GCC back-end limitations. I'm happy to go with just one bit for now, but to be useful I think it has to just mean "suggest" (to be specific: it is a guarantee from the front-end to the back-end about liveness of locals and tail-ness, but there should be no guarantee from the back-end that it will actually use a tail call). > So short-term I'd rather just disable rtl inlining if we > expand a CALL_EXPR with CALL_EXPR_TAILCALL set. OK, shall do. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: < http://www.cs.mu.oz.au/~fjh > | -- the last words of T. S. Garp.