RFR(XS): 8202179: Compilation fails with assert(n->is_expensive()) failed: expensive nodes with non-null control here only
tobias.hartmann at oracle.com
Thu Apr 26 15:59:24 UTC 2018
On 26.04.2018 17:47, Vladimir Kozlov wrote:
> Should we also check in(0) for NULL in Node::is_unreachable() ? I know that is called only for
> expensive nodes *now* but still it should check for 0.
Okay, let's do that:
> On 4/26/18 12:05 AM, Tobias Hartmann wrote:
>> please review the following patch:
>> Expensive nodes have control inputs to prevent GVN from commoning them which may cause more frequent
>> execution (see comment of PhaseIdealLoop::process_expensive_nodes()).
>> Compile::cleanup_expensive_nodes() assumes no expensive nodes are added after parsing and removes
>> the control input if there's only a single copy of a node. ConvD2FNode::Ideal() then creates a new
>> SqrtFNode with the control of the input SqrtDNode (which is NULL).
>> We should only treat the SqrtFNode as expensive if the control input is not NULL.
>> I was only able to reproduce this with replay compilation and a customer application.
>> All tests pass.
More information about the hotspot-compiler-dev