RFR(XS): 8026959: assert(!n->pinned() || n->is_MachConstantBase()) failed: only pinned MachConstantBase node is expected here

Rickard Bäckman rickard.backman at oracle.com
Mon Oct 21 22:48:35 PDT 2013


Igor,

it would be easy to check that the control of a phi isn't NULL.
If we have an out edge from the MathExact and the Phi and MathExact have the same control checking that it is also used as an input is a bit more work since there can be nodes in between.
Should I add a graph traversal?

Thanks
/R


On 10/21, Igor Veresov wrote:
> Would it be prudent to verify (via an assert) all these assumptions about the graph shape you list in the comments?
> 
> igor
> 
> On Oct 21, 2013, at 6:39 AM, Rickard Bäckman <rickard.backman at oracle.com> wrote:
> 
> > Hi,
> > 
> > can I have reviews for this small change?
> > The problem is we are moving a Phi node that is both input and output to
> > a MathExactNode.
> > 
> > Unfortunately cr.openjdk.java.net is down at the moment. I'm pasting the
> > diff below.
> > 
> > diff --git a/src/share/vm/opto/compile.cpp b/src/share/vm/opto/compile.cpp
> > --- a/src/share/vm/opto/compile.cpp
> > +++ b/src/share/vm/opto/compile.cpp
> > @@ -3004,6 +3004,10 @@
> >       if (result != NULL) {
> >         for (DUIterator_Fast jmax, j = result->fast_outs(jmax); j < jmax; j++) {
> >           Node* out = result->fast_out(j);
> > +          // Phi nodes shouldn't be moved. They would only match below if they
> > +          // had the same control as the MathExactNode. The only time that
> > +          // would happen is if the Phi is also an input to the MathExact
> > +          if (!out->is_Phi()) {
> >           if (out->in(0) == NULL) {
> >             out->set_req(0, non_throwing);
> >           } else if (out->in(0) == ctrl) {
> > @@ -3012,6 +3016,7 @@
> >         }
> >       }
> >     }
> > +    }
> >     break;
> >   default:
> >     assert( !n->is_Call(), "" );
> > 
> > 
> > Thank you
> > /R
> 
/R


More information about the hotspot-compiler-dev mailing list