[11] RFR(XS): 8202179: Compilation fails with assert(n->is_expensive()) failed: expensive nodes with non-null control here only

[Tobias Hartmann]

Thanks, Vladimir.

Best regards,
Tobias

On 26.04.2018 18:02, Vladimir Kozlov wrote:
> Good.
> 
> thanks,
> Vladimir
> 
> On 4/26/18 8:59 AM, Tobias Hartmann wrote:
>> Hi Vladimir,
>>
>> 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:
>> http://cr.openjdk.java.net/~thartmann/8202179/webrev.01/
>>
>> Thanks,
>> Tobias
>>
>>> On 4/26/18 12:05 AM, Tobias Hartmann wrote:
>>>> Hi,
>>>>
>>>> please review the following patch:
>>>> https://bugs.openjdk.java.net/browse/JDK-8202179
>>>> http://cr.openjdk.java.net/~thartmann/8202179/webrev.00/
>>>>
>>>> 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.
>>>>
>>>> Thanks,
>>>> Tobias
>>>>