Inconsistency between adr types of ideal and mach loads from conP

[Tom Rodriguez]

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