Modify ADLC to generate meaningful match rules names.
For example, for the next match rule:

instruct addI_rReg_mem(rRegI dst, memory src, rFlagsReg cr)
%{
  match(Set dst (AddI dst (LoadI src)));

instead of the current name:

  __intop25_rule

generate this one:

  _AddI_rRegI__LoadI_memory__rule
Posted Date : 2006-08-16 22:33:34.0

N/A

See Description.
Posted Date : 2006-08-17 00:15:04.0

I'm not sure if this bug was filed because it was the cause of the following problem mentioned in the .ad files (e.g. sparc.ad):

// Due to a shortcoming in the ADLC, it mixes up expressions like:
// (foo (CmpI (CmpL X Y) 0)) and (bar (CmpI (CmpL X 0L) 0)).  Note the 
// difference between 'Y' and '0L'.  The tree-matches for the CmpI sections 
// are collapsed internally in the ADLC's dfa-gen code.  The match for 
// (CmpI (CmpL X Y) 0) is silently replaced with (CmpI (CmpL X 0L) 0) and the 
// foo match ends up with the wrong leaf.  One fix is to not match both 
// reg-reg and reg-zero forms of long-compare.  This is unfortunate because 
// both forms beat the trinary form of long-compare and both are very useful 
// on Intel which has so few registers.

At least the above mentioned comment is still present in the .ad files although the fix for this bug also fixes the problem mentioned in that comment.

The problem was caused by the old match rule name generator that only took into account the opcode of a node and the names of its left and right operand. That's why the two match rules in the example above '(CmpI (CmpL X Y) 0)' and '(CmpI (CmpL X 0L) 0)' where both maped to "CmpI CmpL immL0" (if we assume that the operand type o '0' is 'immL0') before they where hashed to the same generated name (e.g. '__intop25'). Thats why the two instructions with the specialized match rules where finally folded into one rule.

Notice that this bug may also have caused other problems with deeply nested match rules.