RFR(S): 8235762: JVM crash in SWPointer during C2 compilation

[Yangfei (Felix)]

Hi Tobias,

  Thanks for reviewing this.  

> 
> Hi Felix,
> 
> On 12.12.19 07:24, Yangfei (Felix) wrote:
> >   I have created a webrev for the patch:
> http://cr.openjdk.java.net/~fyang/8235762/webrev.00/
> >   Tested tier1-3 with both aarch64 and x86_64 linux release build.
> >   Newly added test case fail without the patch and pass with the patch.
> 
> Thanks for creating a webrev and adding the test. I have some questions:
> - Shouldn't we at least add an assert to verify that after
> SuperWord::find_adjacent_refs() best_align_to_mem_ref != NULL if
> _packset.length() > 0?

-- OK.  I will add one assertion immediately before breaking the loop.  


> - 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.  


> 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.