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