Re: PR3256: Exceptions vs. delay slots

[Jakub Jelinek <jakub at redhat dot com>]

On Thu, Jul 19, 2001 at 01:19:52PM -0700, Mark Mitchell wrote:
> PR3256 (a regresion from GCC 2.95.x) contains code that looks roughly
> like:
> 
>   int f() {
>     int i = 1;
> 
>     try {
>       g();
>       i = 2;
>     } catch (...) {
>     }
> 
>     return i;
>   }
> 
> We brilliantly put the assignment `i = 2' into the delay slot of `g'
> on SPARC.  (In the larger test-case, I don't know if this will happen
> for this tiny test-case.)  This is not good because when we get back,
> after `g' throws an exception, `i' has the wrong value.
> 
> The reason we do this is that `i' is `%l2', and that is not a
> call-clobbered register, so we know there is no conflict between the
> call and the set.  We reason "if the function returns, then `i' will
> be set to `2', so we may as well do it now."
> 
> Oops, but exceptions make life interesting; you can get back to the
> same function without returning from the function call.
> 
> I am thinking that we need to change our delay-slot scheduler to not
> pull instructions from beyond calls that might throw exceptions (i.e,
> calls that are not marked `nothrow' when -fexceptions is turned on).
> Obviously, you could pull instructions if they only affect things that
> will go out of scope before the `catch', etc., etc., but first things
> first.

Cannot this be limited to sets to REG_USERVAR_P() registers?

	Jakub