code optimized away before a deopt

[Deneau, Tom]

Gilles --

By adding another test before the call to DeoptimizeNode.deopt I was able to get the cleanup to happen.
But I agree with Doug, a warning would be helpful in such a situation (for novice snippet writers).

Our situation:

We were experimenting with our own implementation of newInstance snippet.
There are cases when we reach the end of a tlab where
some of the tlab fields are in an inconsistent state and need to be cleaned up
and we also need to end the kernel with an error condition (since we can't yet
recover from this by getting a new tlab in this situation).
But we want to leave the tlab in a consistent state before we exit.

Currently we don't really handle deoptimization yet at all, but it does end up
generating code to return early from the HSAIL kernel.  So calling
DeoptimizeNode.deopt from the snippet seemed like one way to exit early.

However, as I think about it, using DeoptimizeNode.deopt is probably the wrong way to handle 
this early exit situation (especially in light of cleanup code possibly being optimized away).

(although I'm not really sure what other means we could use to early exit).

-- Tom







-----Original Message-----
From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Gilles Duboscq
Sent: Saturday, November 23, 2013 11:27 AM
To: Doug Simon
Cc: Lukas Stadler; graal-dev at openjdk.java.net
Subject: Re: code optimized away before a deopt

To really understand the problem we would probably need to know exactly what you (Tom) are trying to achieve and how the snippet is used (lowering?
of which node? when?...).


On Sat, Nov 23, 2013 at 5:23 PM, Doug Simon <doug.simon at oracle.com> wrote:

>
> On Nov 23, 2013, at 5:18 PM, Lukas Stadler <lukas.stadler at jku.at> wrote:
>
> > But it _is_ ok to remove side effecting nodes, because we know they 
> > will
> be reelected.
>
> Yes, normally, but when you write this pattern in a snippet, then this 
> won’t be true right, since we don’t resume execution in the bytecode 
> of the snippet (yet!). That why I was thinking at least a warning 
> would be a good idea.
>
> -Doug
>
> > Maybe the cleanup operations could be part of a special purpose 
> > deopt
> node?
> >
> > - Lukas
> >
> > Von meinem iPhone gesendet
> >
> >> Am 23.11.2013 um 16:39 schrieb Doug Simon <doug.simon at oracle.com>:
> >>
> >> This is done by the ConvertDeoptimizeToGuardPhase which replaces
> conditionals where one branch ends in a deopt with a GuardNode. This 
> does indeed have the side effect of (silently) deleting all other 
> nodes on that deopt-terminated branch. We should add some code to 
> either make the deletion not silent or better, throw an error if these 
> are any side-effecting nodes that will be deleted.
> >>
> >> -Doug
> >>
> >>> On Nov 23, 2013, at 1:58 AM, Deneau, Tom <tom.deneau at amd.com> wrote:
> >>>
> >>> I've noticed that if I have a snippet that does a test and if the 
> >>> test
> fails, branches to a block that does some cleanup operations and then 
> calls DeoptimizeNode.deopt(xxx, yyy), the cleanup code  gets 
> "optimized away".  I guess this is related to what Gilles was talking 
> about, maybe the cleanup operations were considered not state changing?
> >>>
> >>> In our current state of HSAIL backend, a deopt just returns early 
> >>> from
> the kernel.   Is there something I can do to make the cleanup code get
> emitted before the deopt?
> >>>
> >>> -- Tom
> >>
>
>