This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Non-call exceptions versus cse
- From: Geert Bosch <bosch at gnat dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 19 Nov 2002 17:01:25 -0500
- Subject: Re: Non-call exceptions versus cse
On Tuesday, Nov 19, 2002, at 11:21 America/New_York, Andrew Haley wrote:
As far as I can see it's never correct to CSE two instructions if the
first one may trap.
This will severely harm performance with non-call exceptions.
For languages such as Ada that need non-call exceptions to work for
implementing language-defined checks, and allow such exceptions
to be raised at an arbitrary point in a function, it should be
possible to retain the current behavior.
The exact semantics for Ada are (from Ada RM95 11.4):
4. The following additional permissions are granted to the
implementation:
5. An implementation need not always raise an exception when a
language-defined check fails. Instead, the operation that
failed the check can simply yield an undefined result. The
exception need be raised by the implementation only if, in
the absence of raising it, the value of this undefined result
would have some effect on the external interactions of the
program. In determining this, the implementation shall not
presume that an undefined result has a value that belongs to
its subtype, nor even to the base range of its type, if
scalar. Having removed the raise of the exception, the
canonical semantics will in general allow the implementation
to omit the code for the check, and some or all of the
operation itself.
6. If an exception is raised due to the failure of a
language-defined check, then upon reaching the corresponding
exception_handler (or the termination of the task, if none),
the external interactions that have occurred need reflect
only that the exception was raised somewhere within the
execution of the sequence_of_statements with the handler (or
the task_body), possibly earlier (or later if the
interactions are independent of the result of the checked
operation) than that defined by the canonical semantics, but
not within the execution of some abort-deferred operation or
independent subprogram that does not dynamically enclose the
execution of the construct whose check failed. An
independent subprogram is one that is defined outside the
library unit containing the construct whose check failed, and
has no Inline pragma applied to it. Any assignment that
occurred outside of such abort-deferred operations or
independent subprograms can be disrupted by the raising of
the exception, causing the object or its parts to become
abnormal, and certain subsequent uses of the object to be
erroneous, as explained in *Note 13.9.1::.