>> Tom Rodriguez wrote:
>>> Here's a side question:  when matching a memory node we should expect 
>>> that the adr_type doesn't change.  Is there an obvious place to put 
>>> an assert about that during matching?  It's complicated because of 
>>> matches with multiple nodes but it would be nice to catch these 
>>> problems immediately.
>
> Vladimir Kozlov wrote:
>> So you want to add an additional adr_type field to all memory mach nodes
>> during matching and then compare in assert the result of MachNode::adr_type()
>> and this field. Is is correct? I will file a bug to investigate it.
>
Tom Rodriguez wrote: 
> Actually that's a  customer  idea too.  Regular memnodes do something like 
> that right now I think to check that the adr_type doesn't change over 
> time.  I was just thinking that we should verify that the adr_type of 
> the ideal node matches the adr_type of the machnode that is produced for 
> it at match time.  Basically the adr_type shouldn't change from the time 
> the ideal memory operation is constructed to the time we emit assembly 
> for it.  We'd have caught this pretty early if we had these checks in 
> place.
Posted Date : 2008-06-17 18:08:09.0

N/A

MachNode::get_base_and_disp() does not process correctly
an addressing with a narrow oop LoadConN node (is_Con() == true).
As result the adr_type() for such addresses is "BotPTR* + bot"
which aliases with all stores.

The mach node loadNKlass has wrong bottom_type() since
its base class is not MachTypeNode (as for loadKlass)
because we missed it in InstructForm::captures_bottom_type).

DecodeN::value() and EncodeN::value() always return the type
with which a node was created when it should return the type
based on the type of the current input node (which could be
different from an original input node).
Posted Date : 2008-06-20 22:02:28.0