[9] RFR(S): 8079343: Crash in PhaseIdealLoop with "assert(!had_error) failed: bad dominance"
Vladimir Kozlov
vladimir.kozlov at oracle.com
Fri May 8 18:16:43 UTC 2015
Looks good.
Thanks,
Vladimir
On 5/8/15 5:18 AM, Tobias Hartmann wrote:
> Hi,
>
> please review the following patch.
>
> https://bugs.openjdk.java.net/browse/JDK-8079343
> http://cr.openjdk.java.net/~thartmann/8079343/webrev.00/
>
> Problem:
> The regression test for JDK-8078497 [1] fails with "assert(!had_error) failed: bad dominance" because during loop optimizations a node in the pre-loop has a control node in the main-loop. The test looks like this:
>
>
> byte[] src = src1;
>
> for (int i = ...) {
>
> // Copy 8 chars from src to dst
>
> ...
>
> // Prevent loop invariant code motion of char read.
>
> src = (src == src1) ? src2 : src1;
>
> }
>
>
>
> The problem is that the superword optimization tries to vectorize the 8 load char / store char operations in the loop. In 'SuperWord::align_initial_loop_index' the base address of the memory operation we align the loop to ('align_to_ref_p.base()') is not loop invariant because 'src' changes in each iteration. However, we use it's value to correctly align the address if 'vw > ObjectAlignmentInBytes' (see line 2344). This is wrong because the address changes in each iteration. It also causes follow up problems in 'PhaseIdealLoop::verify_dominance' because nodes in the pre-loop have a control in the main-loop.
>
>
> Solution:
> I agreed with Vladimir K. that we should not try to vectorize such edge cases. I added a check to the constructor of SWPointer to bail out in case the base address is loop variant.
>
> Testing:
> - Regression test
> - JPRT (together with fix for JDK-8078497)
>
> Thanks,
> Tobias
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8078497
>
More information about the hotspot-compiler-dev
mailing list