[15] RFR(S): 8248845: AArch64: stack corruption after spilling vector register

[Vladimir Kozlov]

Thank you, Nick

You are absolutely right that it was mistake change in 8076276. And we don't do scheduling for x86.
Do you need sponsorship for push? The fix is trivial and should be pushed into jdk/jdk15.

Thanks,
Vladimir

On 7/6/20 11:58 PM, Nick Gasson wrote:
> Hi,
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8248845
> Webrev: http://cr.openjdk.java.net/~ngasson/8248845/webrev.0/
> 
> This crash was seen on the Panama vectorIntrinsics branch and a minimal
> test case is attached to the JBS entry, but it should also affect
> vanilla jdk/jdk although I haven't found a reliable way to reproduce it.
> 
>    0x0000ffffa173fd40:   ldr	x11, [sp, #120]
>    0x0000ffffa173fd44:   ldr	x10, [sp, #48]
>    0x0000ffffa173fd48:   add	x10, x10, x11
>    0x0000ffffa173fd4c:   str	q16, [x10, #16]    ; <==== CRASH HERE
> 
> X10 loaded from sp+48 contains a valid pointer but X11 from sp+120
> contains a garbage value. Here's the relevant opto assembly that spills
> to sp+120:
> 
>    6b4 +   spill [sp, #80] -> [sp, #16]	# vector spill size = 128
>    6bc +   spill [sp, #24] -> [sp, #120]	# spill size = 64
> 
> These two instructions have been scheduled in the wrong order: 6b4
> writes 16 bytes at sp+16 which overwrites another live value at sp+24.
> Instruction 6bc spills the clobbered value at sp+24 to sp+120. If I dump
> out the instructions before scheduling or pass -XX:-OptoScheduling the
> order is correct.
> 
> It seems to be a known limitation that the scheduler doesn't correctly
> compute anti-dependencies when a vector occupies more than two slots,
> because PhaseOutput::ScheduleAndBundle() already has a check to skip
> scheduling if a too-wide vector was generated. Unfortunately the check
> is wrong as a pair of slots is 8 bytes not 16:
> 
>    // Scheduling code works only with pairs (16 bytes) maximum.
>    if (C->max_vector_size() > 16)
> 
> Actually the test here used to be > 8, but was changed as part of
> JDK-8076276 which added AVX512 support [1]. I couldn't see any
> explanation of that change in the bug or mailing list thread, but it
> seems wrong and reverting it fixes this crash.
> 
> This affects AArch64 because OptoScheduling is enabled by default and
> NEON vectors are 16 bytes wide.
> 
> Tested hotspot_all_no_apps, jdk_core on AArch64 and x86_64.
> 
> [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-April/017579.html
> 
> --
> Thanks,
> Nick
>