This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Sibcalls and exceptions


On Nov 26, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

> --On Sunday, November 25, 2001 01:29:19 PM +0000 Jason Merrill
> <jason@redhat.com> wrote:

>>>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
>> 
>>> I don't see why this patch:
>> 
>>> 2001-06-05  Mark Mitchell  <mark@codesourcery.com>
>> 
>>> * toplev.c (main): Disable sibling-call optimization if we are
>>> handling exceptions.
>> 
>>> is necessary.
>> 
>> Furthermore, an optimization should never be disabled based on
>> flag_exceptions; if the optimization isn't yet exception-savvy, it should
>> be disabled on a per-function basis, based on whether or not the function
>> in question can throw.

> IIRC, Richard, Jeff, and I collaborated on this patch.

Shouldn't the ChangeLog have reflected this fact? :-D

> We concluded that the sibling call optimization simply was not
> exception safe as implemented.  Is there anything in the archives
> about this?

Dunno, I haven't searched.  I'd have expected any known problems to
show up in the testsuite, and the testsuite didn't reveal any problems
as a result of reverting the patch.

> I do not think we need to do anything for the branch.

Definitely not.

> The mainline is another story; if we can remove the restriction from
> my patch, that's great.  At the least, Jason's idea is a good one,
> and a patch to do that is pre-approved.

Without knowing what problems to look for to disable sibcalls it's a
bit hard to tell when it's safe to try it.

The only EH-related problem I can see regarding sibcalls is:

- caller has a handler that would have been disabled should the callee
  be sibcalled.  This shouldn't be an issue for the call should have
  an edge to the handler if it could possibly throw, which would then
  disable the sibcall at that point.

We needn't do it for the whole function, only for calls for which we
have known handlers.  I haven't checked whether the current code
already has it, but am I missing anything else?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]