replacing nodes with DeoptimizeNodes
Deneau, Tom
tom.deneau at amd.com
Thu Mar 6 15:32:43 PST 2014
Just playing around, wanted to see what would happen if I made all NewInstance nodes deopt.
In reality we would handle fastpath and medium slow path allocations thru hsail and only deopt if say we could not get a new tlab, etc.
-- Tom
> -----Original Message-----
> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com]
> Sent: Thursday, March 06, 2014 5:28 PM
> To: Deneau, Tom
> Cc: Gilles Duboscq; Douglas Simon; graal-dev at openjdk.java.net
> Subject: Re: replacing nodes with DeoptimizeNodes
>
> It's probably not the best place to do it, though it could be made to
> work. 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