RFR(S): 8235762: JVM crash in SWPointer during C2 compilation
Yangfei (Felix)
felix.yang at huawei.com
Fri Jan 10 01:13:23 UTC 2020
Hi Tobias,
Updated webrev: http://cr.openjdk.java.net/~fyang/8235762/webrev.01/
This also updated copyright years of the newly-added test case.
Still test OK with the latest repo. Is this one better?
Thanks,
Felix
>
> Hi Felix,
>
> On 16.12.19 11:14, Yangfei (Felix) wrote:
> > -- OK. I will add one assertion immediately before breaking the loop.
>
> Thanks.
>
> >> - Why do you need max_idx? Isn't is the case that if
> >> find_align_to_ref returns NULL, there aren't any comparable memory
> >> operations left and it essentially doesn't matter which one you chose?
> >
> > -- I was considering minimizing the performance impact of the patch here.
> > best_align_to_mem_ref is used in SuperWord::align_initial_loop_index for
> adjusting the pre-loop limit.
> > For the test case in the webrev, best_align_to_mem_ref was chosen from
> node 470 (StoreB) and node 431 (StoreL).
> > The vector width for these two memory operations are different on
> aarch64 platform: vw = 16 bytes for node 431 and 2 bytes for node 470.
> > SuperWord::align_initial_loop_index will emit different code sequences for
> the test case.
> > The max_idx tells us which memory operation has the biggest vector size.
>
> Okay, thanks for the details. Could you add a comment that explains this?
>
> >> Also, is it guaranteed that max_idx is always initialized in
> SuperWord::find_align_to_ref?
> >
> > -- Yes, I think so.
> > When memops is not empty and the memory ops in memops are not
> comparable, find_align_to_ref will always sets its max_idx.
>
> Okay.
>
> Thanks,
> Tobias
More information about the hotspot-compiler-dev
mailing list