RFR(S): 8134974: 8130847 broken with loop predicates

[Vladimir Kozlov]

Good.

Thanks,
Vladimir

On 9/14/15 5:43 AM, Roland Westrelin wrote:
> Here is a different fix for this issue:
>
> http://cr.openjdk.java.net/~roland/8134974/webrev.01/
>
> When the region that merges several predicate paths is created, the control of the Loads & Stores is moved to that region. The reason I want to go with this fix is that I noticed that sometimes, PhaseIdealLoop::try_move_store_after_loop() would sink a Store in a loop predicate uncommon trap path before the region is created. This new fix covers both the eliminated arraycopy and sunk Store cases.
>
> Roland.
>
>
>> On Sep 8, 2015, at 8:59 PM, Roland Westrelin <roland.westrelin at oracle.com> wrote:
>>
>> I’m withdrawing that RFR, at least for now, as I’m investigating an alternate, more general fix.
>>
>> Roland.
>>
>>
>>> On Sep 4, 2015, at 9:31 AM, Roland Westrelin <roland.westrelin at oracle.com> wrote:
>>>
>>> http://cr.openjdk.java.net/~roland/8134974/webrev.00/
>>>
>>> At a deoptimization point, loads that capture the state of an eliminated allocation which is the destination of an arraycopy are pinned on the uncommon trap path. If that uncommon trap is for loop predicates then pinning the loads on that path may lead to a broken graph: the allocation may be eliminated as early as right after escape analysis, following loop optimizations may add predicates which require a new region to be added and then the control of the loads no longer dominates the uncommon trap.
>>>
>>> Roland.
>>
>