replacing nodes with DeoptimizeNodes

Doug Simon doug.simon at oracle.com
Fri Mar 7 02:28:05 PST 2014


On Mar 7, 2014, at 12:28 AM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:

> It’s probably not the best place to do it, though it could be made to work.

I agree - you want to do this in a separate phase.

>  What kinds of operations are you converting into deopts?
> 
> tom
> 
> On Mar 6, 2014, at 3:25 PM, Deneau, Tom <tom.deneau at amd.com> wrote:
> 
>> Yes, it's happening as a result of my conversion of a node into a Deopt
>> node?  Which I was trying to do during lowering.  Maybe that's the wrong place to do it?
>> 
>> -- Tom
>> 
>>> -----Original Message-----
>>> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com]
>>> Sent: Thursday, March 06, 2014 5:17 PM
>>> To: Deneau, Tom
>>> Cc: Gilles Duboscq; Douglas Simon; graal-dev at openjdk.java.net
>>> Subject: Re: replacing nodes with DeoptimizeNodes
>>> 
>>> 
>>> On Mar 6, 2014, at 12:21 PM, Deneau, Tom <tom.deneau at amd.com> wrote:
>>> 
>>>> OK, and if I get an error like
>>>> lowering of NodeA produced lowerable NodeB that should have been
>>>> recursively lowered as it introduces these new nodes: [171|Deopt]
>>>> 
>>>> does that mean I have to write my own lowering for NodeA which as part
>>> of that also lowers the replacement nodeB?
>>> 
>>> Generally any lowering phase is required to finish in a single pass, so
>>> if you're lowering is doing anything tricky that introduces Lowerable
>>> nodes than you need to manually lower them, usually by running your own
>>> LoweringPhase.  When are you getting this message?  MacroNodes do this
>>> for instance.
>>> 
>>> Is this happening as a result of your conversion of a node into a Deopt
>>> node?  Are you trying to do that during lowering?
>>> 
>>> tom
>>> 
>>>> 
>>>> -- Tom
>>>> 
>>>>> -----Original Message-----
>>>>> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of
>>>>> Gilles Duboscq
>>>>> Sent: Wednesday, March 05, 2014 4:29 AM
>>>>> To: Doug Simon
>>>>> Cc: Deneau, Tom; graal-dev at openjdk.java.net
>>>>> Subject: Re: replacing nodes with DeoptimizeNodes
>>>>> 
>>>>> On Wed, Mar 5, 2014 at 11:18 AM, Doug Simon <doug.simon at oracle.com>
>>>>> wrote:
>>>>>> 
>>>>>> On Mar 5, 2014, at 1:27 AM, Deneau, Tom <tom.deneau at amd.com> wrote:
>>>>>> 
>>>>>>> Let's say there is some random graal node that you choose not to
>>>>> implement so you want it to be replaced by a DeoptimizeNode.  How
>>>>> does one do that if the original node is not a terminal node, ie, it
>>>>> has usages?
>>>>>> 
>>>>>> The subgraph rooted at that node has to be removed (probably through
>>>>> use of
>>>>> com.oracle.graal.nodes.util.GraphUtil.killWithUnusedFloatingInputs(No
>>>>> de)
>>>>> ).
>>>>> 
>>>>> Rather GraphUtil.killCFG(Node).
>>>>> As an example, you can look at CanonicalizerPhase.performReplacement
>>>>> (around line 297):
>>>>> //case 7
>>>>> fixed.predecessor().replaceFirstSuccessor(fixed, canonical);
>>>>> GraphUtil.killCFG(fixed);
>>>>> 
>>>>> even better would be:
>>>>> fixed.replaceAtPredecessor(canonical);
>>>>> GraphUtil.killCFG(fixed);
>>>>> 
>>>>> where in you case fixed is the node you want to replace and canonical
>>>>> is the DeoptimizeNode.
>>>>> 
>>>>>> 
>>>>>> -Doug
>>>> 
>>> 
>> 
>> 
> 



More information about the graal-dev mailing list