Inconsistency between adr types of ideal and mach loads from conP

[Vladimir Kozlov]

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