RFR: 8262341: Refine identical code in AddI/LNode.

Roland Westrelin roland at openjdk.java.net
Tue Nov 30 08:48:20 UTC 2021


AddINode::Ideal() and AddlNode::Ideal() are almost identical but the
same logic had to be duplicated because AddINode::Ideal() tests its
inputs for Op_AddI, Op_SubI etc. while AddLNode::Ideal() tests for
Op_AddL, Op_SubL etc. This patch refactors the code so the common
logic is in a single method parameterized by a BasicType argument.

The way I've done this before in the context of int/long counted loops
was to use and extra virtual method operates_on(). So:

n->Opcode() == Op_AddI becomes n->is_Add() && n->operates_on(T_INT)

Working on this change made me realize that pattern doesn't work that well:

- it's quite a bit more verbose and converting existing code is not as
  mechanical as we would like to avoid conversion errors.

- it breaks when a class has a subclass. For instance AddNode has
  OrINode and OrLNode as subclasses so testing for n->is_Add() returns
  true with an OrI node.

Instead, this change introduces new functions. For instance of
AddI/AddL:

int Op_Add(BasicType bt)

that returns either Op_AddI or Op_AddL depending on bt. This made
refactoring the AddINode::Ideal() logic straightforward. I removed all
use of operates_on() as well and converted existing code to the new
Op_XXX() functions.

-------------

Commit messages:
 - fix

Changes: https://git.openjdk.java.net/jdk/pull/6607/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6607&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262341
  Stats: 433 lines in 14 files changed: 120 ins; 249 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6607.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6607/head:pull/6607

PR: https://git.openjdk.java.net/jdk/pull/6607


More information about the hotspot-compiler-dev mailing list