[15] RFR(S): 8241997: Scalar replacement of cloned array is broken after JDK-8238759

[Nils Eliasson]

Thanks for the explanation.

I think there will be more opportunities for cleaning up cloning 
optimizations. The array-clone should just be the special case of acopy 
where the full array is copied, and which can't fault on index or type 
check.

Your change fixes a performance issue I have seen, but didn't understood 
that I caused it :)

Best regards,

// Nils

On 2020-04-06 08:23, Tobias Hartmann wrote:
> Hi Nils,
>
> thanks for the review!
>
> On 03.04.20 17:29, Nils Eliasson wrote:
>> Nice find - but not all changes in macro.cpp seems related to what was caused by JDK-8238759. What
>> are the additional changes in PhaseMacroExpand::process_users_of_allocation and
>> PhaseMacroExpand::can_eliminate_allocation motivated by?
> Changes in 'can_eliminate_allocation'
> - line 675: Check is always false since an allocation result is not connected to a clonebasic
> through an AddP anymore.
> - line 686: Instead, clonebasic is now directly connected to the allocation through the
> ArrayCopyNode::Dest input.
>
> Changes to 'process_users_of_allocation':
> - line 970: This is a bit hard to follow in the webrev. I've moved the clonebasic handling from the
> use->is_AddP() branch to the use->is_ArrayCopy() branch, again because the clonebasic is now
> directly connected through the result cast and not indirectly through an AddP.
>
> Best regards,
> Tobias