United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6715633 when matching a memory node the adr_type should not change
6715633 : when matching a memory node the adr_type should not change

Details
Type:
Enhancement
Submit Date:
2008-06-17
Status:
Resolved
Updated Date:
2010-04-03
Project Name:
JDK
Resolved Date:
2008-07-02
Component:
hotspot
OS:
solaris_10
Sub-Component:
compiler
CPU:
x86
Priority:
P4
Resolution:
Fixed
Affected Versions:
hs14
Fixed Versions:
hs14

Related Reports
Backport:
JDK-2172704 - when matching a memory node the adr_type should not change
Backport:
JDK-2177170 - when matching a memory node the adr_type should not change
Relates:
JDK-6731641 - assert(m->adr_type() == mach->adr_type(),"matcher should not change adr type")

Sub Tasks

Description
>> 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 good 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.

Comments
SUGGESTED FIX

Added the debug field _mem_node to Matcher class and set it to
a memory node which is consumed by a mach node. Use it to
verify the adr_type of the mach node which should not change.
This check found the listed type problems.
Put opaque nodes on the macro nodes list to remove them during
macro expansion phase and to execute igvn transformations on users.
2008-06-20 
EVALUATION

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).
2008-06-20


Hardware and Software, Engineered to Work Together