Inconsistency between adr types of ideal and mach loads from conP

[Tom Rodriguez]

Sounds good.

tom

On Jul 6, 2009, at 6:06 PM, Vladimir Kozlov wrote:

> I can't recall it now but most likely I thought rawptr mismatching
> does not affect code correctness.
> The cutout is not needed with the suggested fix.
>
> Vladimir
>
> Tom Rodriguez wrote:
>> Shouldn't the assert you added a while back have caught this?  Oh,  
>> I see it has a cutout for rawptr which would have kept it from  
>> checking.  Why does this cutout exist?
>> tom
>> On Jul 2, 2009, at 5:49 PM, Vladimir Kozlov wrote:
>>> Thanks, Tom
>>>
>>> the failed before compilation passed with this fix:
>>>
>>> @@ -300,6 +300,12 @@ const Node* MachNode::get_base_and_disp(
>>>          }
>>>        }
>>>        adr_type = t_disp->add_offset(offset);
>>> +      } else if( base == NULL && offset != 0 && offset !=  
>>> Type::OffsetBot ) {
>>> +        // Use ideal type if it is ptr.
>>> +        const TypePtr *tp = oper->type()->isa_ptr();
>>> +        if( tp != NULL ) {
>>> +          adr_type = tp;
>>> +        }
>>>      }
>>>    }
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> Tom Rodriguez wrote:
>>>> I think MemNode::adr_type is the one we consider to be correct  
>>>> since that's the one used for all the optimizations.   
>>>> MachNode::adr_type needs to return the same answer or at least an  
>>>> equivalent answer from an aliasing standpoint.
>>>> tom
>>>> On Jul 2, 2009, at 10:59 AM, Vladimir Kozlov wrote:
>>>>> While testing my changes for StoreOop macro node with CTW rt.jar
>>>>> I hit this problem.
>>>>>
>>>>> In ideal graph load from ConP has exact adr type and its memory
>>>>> edge is immutable memory:
>>>>>
>>>>> [t at 21 l at 21]: print m._new2old_map[133]->dump(2)
>>>>> o3      Start   === o3 o0  [[o3 o5 o6 o7 o8 o9 ]]  #{0:control,  
>>>>> 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address}
>>>>> o73     Initialize      === o3560 o1 o76 o1 o1 o1 o3561  [[o74  
>>>>> o75 ]]
>>>>> o97     ConP    === o0  [[ ... o3500 ... ]]  #java/lang/ 
>>>>> Class:exact *  Oop:java/lang/Class:exact *
>>>>> o7      Parm    === o3  [[ ... o3500 o3510 ]] Memory  Memory:  
>>>>> @BotPTR *+bot, idx=Bot;
>>>>> o74     Proj    === o73  [[o3504 o77 o3500 ]] #0
>>>>> o3500   LoadI   === o74 o7 o97  [[o3501 o3514 o3752 o3530  
>>>>> o3538 ]]  @java/lang/Class:exact *, idx=11; #int
>>>>>
>>>>> [t at 21 l at 21]: print m._new2old_map[133]->as_Mem()->adr_type()- 
>>>>> >dump()
>>>>> java/lang/Class:exact *
>>>>>
>>>>> But corresponding mach load has rawptr type since the "direct"  
>>>>> address
>>>>> has only offset "disp" and no base:
>>>>>
>>>>> [t at 21 l at 21]: print load->dump(2)
>>>>> 91     Start   ===  91  1  [[ 91  90  92  ... ]]  #{0:control,  
>>>>> 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address} !jvms:  
>>>>> KeyStroke::getKeyStroke @ bci:17 MotifTextUI::<clinit> @ bci:14
>>>>> 68     Initialize      ===  69  0  124  0  0  0  125  [[ 67   
>>>>> 144 ]]  !jvms: MotifTextUI::<clinit> @ bci:6
>>>>> 92     MachProj        ===  91  [[ ...  113  ... ]] #2/ 
>>>>> unmatched  Memory: @BotPTR *+bot, idx=Bot; !jvms:  
>>>>> MotifTextUI::<clinit> @ bci:-1
>>>>> 67     MachProj        ===  68  [[ 63  133  168 ]] #0/unmatched ! 
>>>>> jvms: MotifTextUI::<clinit> @ bci:6
>>>>> 133    loadI   ===  67  92  [[ 65  134  146  145  165 ]] java/ 
>>>>> lang/Class:exact *
>>>>>
>>>>> [t at 21 l at 21]: print load->adr_type()->dump()
>>>>> rawptr:BotPTR
>>>>>
>>>>> class TypePtr* MachNode::adr_type() {
>>>>> ...
>>>>> // Direct addressing modes have no base node, simply an indirect
>>>>> // offset, which is always to raw memory.
>>>>> if (base == NULL) {
>>>>>  ...
>>>>>  // %%% make offset be intptr_t
>>>>>  assert(!Universe::heap()->is_in_reserved((oop)offset), "must be  
>>>>> a raw ptr");
>>>>>  return TypeRawPtr::BOTTOM;
>>>>> }
>>>>>
>>>>>
>>>>> When the mach load is processed in  
>>>>> PhaseCFG::insert_anti_dependences()
>>>>> it became anti-dep on the Initialize node (which also has  
>>>>> rawptr:BotPTR type)
>>>>> at the same block:
>>>>>
>>>>>  } else {
>>>>>    // Found a possibly-interfering store in the load's 'early'  
>>>>> block.
>>>>>    // This means 'load' cannot sink at all in the dominator tree.
>>>>>    // Add an anti-dep edge, and squeeze 'load' into the highest  
>>>>> block.
>>>>>    assert(store != load->in(0), "dependence cycle found");
>>>>>    if (verify) {
>>>>>      assert(store->find_edge(load) != -1, "missing precedence  
>>>>> edge");
>>>>>    } else {
>>>>>      store->add_prec(load);
>>>>>    }
>>>>>
>>>>> 68     Initialize      ===  69  0  124  0  0  0  125  | 133   
>>>>> [[ 67  144 ]]  !jvms: MotifTextUI::<clinit> @ bci:6
>>>>> 67     MachProj        ===  68  [[ 63  133  168 ]] #0/unmatched ! 
>>>>> jvms: MotifTextUI::<clinit> @ bci:6
>>>>> 133    loadI   ===  67  92  [[ 65  134  146  145  165  68 ]]  
>>>>> java/lang/Class:exact *
>>>>>
>>>>> And this screw up local scheduling since the load has the control
>>>>> edge after the Initialize.
>>>>>
>>>>> Note: in 64-bit VM "direct" address mode is not available.
>>>>>
>>>>> Should I fix MemNode::adr_type() to return rawptr type for such  
>>>>> case or
>>>>> MachNode::adr_type() to return exact type?
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>