Inconsistency between adr types of ideal and mach loads from conP

[Vladimir Kozlov]

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