[9] RFR(S): 8079343: Crash in PhaseIdealLoop with "assert(!had_error) failed: bad dominance"

Tobias Hartmann tobias.hartmann at oracle.com
Mon May 11 05:33:16 UTC 2015


Thanks, Vladimir.

Best,
Tobias

On 08.05.2015 20:16, Vladimir Kozlov wrote:
> 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