openjdk/jdk · critical

Ideal node missing: %s

Error message

Ideal node missing: %s

What it means

ArchDesc::addForm/MatchRule processing error: the match rule's root operator (result type, looked up via getMatchListIndex and _idealIndex) has no index among the ideal (IR) nodes. The .ad file's match rule produces a node type that was never declared/registered as an ideal node, so ADLC cannot place the rule into the matcher DFA. An assert follows in debug builds of adlc; behavior is undefined in release adlc.

Source

Thrown at src/hotspot/share/adlc/archDesc.cpp:484

// operands and instructions provide the result
void ArchDesc::buildMatchList(MatchRule *mrule, const char *resultStr,
                              const char *rootOp, Predicate *pred,
                              const char *cost) {
  const char *leftstr, *rightstr;
  MatchNode  *mnode;

  leftstr = rightstr = nullptr;
  // Check for chain rule, and do not generate a match list for it
  if ( mrule->is_chain_rule(_globalNames) ) {
    return;
  }

  // Identify index position among ideal operands
  intptr_t    index     = _last_opcode;
  const char  *indexStr  = getMatchListIndex(*mrule);
  index  = (intptr_t)_idealIndex[indexStr];
  if (index == 0) {
    fprintf(stderr, "Ideal node missing: %s\n", indexStr);
    assert(index != 0, "Failed lookup of ideal node\n");
  }

  // Check that this will be placed appropriately in the DFA
  if (index >= _last_opcode) {
    fprintf(stderr, "Invalid match rule %s <-- ( %s )\n",
            resultStr ? resultStr : " ",
            rootOp    ? rootOp    : " ");
    assert(index < _last_opcode, "Matching item not in ideal graph\n");
    return;
  }


  // Walk the MatchRule, generating MatchList entries for each level
  // of the rule (each nesting of parentheses)
  // Check for "Set"
  if (!strcmp(mrule->_opType, "Set")) {
    mnode = mrule->_rChild;

View on GitHub (pinned to 88dfb74bbe)

Solutions

  1. Check the spelling of the result/root operator named in the message against the ideal node list (globals, machine-independent match)
  2. Register the new ideal node name before referencing it in match rules
  3. If porting, map old ideal names to their current HotSpot equivalents
Defensive patterns

Strategy: validation

Validate before calling

# before building, check every match-rule result type is a known ideal name
grep -oP 'match\(\s*(\w+)' src/hotspot/cpu/x86/x86.ad | sort -u | while read _ n; do grep -q "\b$n\b" src/hotspot/share/opto/classes.hpp || echo "unknown result type: $n"; done

Prevention

When it happens

Trigger: A 'instruct' whose match result type or whose root operator in the match rule is misspelled or not an ideal node (e.g. matching a custom 'MyNode' that is not defined in the globals/ideal list). is_chain_rule() rules are exempt; everything else must resolve in _idealIndex.

Common situations: Adding a new ideal node but forgetting to register it in the global name table; typos in the match-rule root operator; porting .ad files when an ideal node was renamed between HotSpot versions.

Related errors


AI-assisted analysis of openjdk/jdk@88dfb74bbe (2026-08-14). Data as JSON: /api/errors/558e0fc92b12b6f9. Report an issue: GitHub.