Inconsistency between adr types of ideal and mach loads from conP

[Tom Rodriguez]

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
>