Inconsistency between adr types of ideal and mach loads from conP

[Vladimir Kozlov]

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