RFR: 8288467: remove memory_operand assert for spilled instructions [v2]

[Emanuel Peter]

On Tue, 21 Jun 2022 15:15:51 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/share/opto/chaitin.cpp
>>   
>>   fix typo
>>   
>>   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>
> Hi @eme64,
> Thanks for pointing this out. Original bug was related to incorrect scheduling of CISC node with just the stack operand which was circumvented by adding a precedence edge from incoming spill copy node. In general there is always a 1-1 correspondence b/w memory_operand index of CISC instruction and cisc_operand index of non-CISC counterpart.
> 
> As you mentioned there are not many cases where an instruction accept more than one memory operand.
> 
> Following patterns in x86_32.ad (which are relevant to SSE targets) are the only occurrences accepting more than one memory operand.
>  
> instruct addFPR24_mem_cisc(stackSlotF dst, memory src1, memory src2) %{
> instruct addFPR24_mem_mem(stackSlotF dst, memory src1, memory src2) %{
> instruct mulFPR24_mem_mem(stackSlotF dst, memory src1, memory src2) %{
> 
> And for each of these a constant -1 value is returned as memory_operand currently. 
> 
>  const MachOper* addFPR24_mem_ciscNode::memory_operand() const { return (MachOper*)-1; }
> const MachOper* addFPR24_mem_cisc_0Node::memory_operand() const { return (MachOper*)-1; }
> const MachOper* addFPR24_mem_memNode::memory_operand() const { return (MachOper*)-1; }
> const MachOper* mulFPR24_mem_memNode::memory_operand() const { return (MachOper*)-1; }
> 
> Post matcher operand array is sacrosanct, only problem here is that oper_input_base() for **non-cisc counterparts** are 2 since first input is memory edge.  Due to this it enters the control flow having assertion check.  
> 
> Your fix to remove assertion, looks safe to me.
> 
> Best Regards,
> Jatin

Thanks @jatin-bhateja @shipilev @TobiHartmann for your reviews, and help with clarifying, verifying and even testing.

-------------

PR: https://git.openjdk.org/jdk19/pull/33