UnwindNode and deoptimization

[Deneau, Tom]

Just to close the loop on this, this was answered in the Skype call with Gilles and Doug,
and the proper way to handle this is to transform the UnwindNode into a DeoptimizeNode
in one of the earlier lowering phases.  (which should make things much simpler).

-- Tom

> -----Original Message-----
> From: Deneau, Tom
> Sent: Monday, December 16, 2013 10:14 AM
> To: graal-dev at openjdk.java.net
> Subject: UnwindNode and deoptimization
> 
> Gilles, Doug, etc. ---
> 
> In our recent hsail backend deoptimization experiments, as mentioned
> previously, we noticed that something like a BoundsCheckException can be
> presented to the LIR as either a DeoptimizeNode or an UnwindNode (the
> UnwindNodes came if there was profiling information I think).
> 
> Anyway, since we want to handle both of these the same way, namely
> deoptimizing, when we saw un UnwindNode, we were getting our
> LIRFrameState by looking at the deoptState of the ForeignCallNode
> exception that is part of the unwindNode.
> 
> I noticed in a sync with the latest trunk that this infrastructure has
> changed now and the ForeignCallNode will often have a deoptState of
> null.  I see that there is a deoptState on the ForeignCallNode.next
> which is a NullCheckNode which I suppose could be used but  I'm not sure
> that's the right approach.
> 
> I was wondering what is the "right" way to handle this.  I think the
> high level summary is that if in the HSAIL backend we are presented with
> an UnwindNode with an associated ForeignCallNode, we cannot handle the
> ForeignCall in HSAIL and would like to treat this as a deoptimization.
> Is there some node transformation perhaps that we should be doing to
> accomplish this?
> 
> -- Tom
>