UnwindNode and deoptimization

[Deneau, Tom]

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