Decouple Data Type from Register Type in OMR::DataType to Prevent Misallocation

[ehsankianifar]

Summary

A bug was recently identified in the Global Register Assigner (GRA), where a mask type was incorrectly assigned a general-purpose register (GPR) instead of a vector register (VRF). This occurred because GRA was determining register type based solely on the data type, and the mask type was not properly accounted for.

Proposal

To prevent such issues in the future, we propose introducing a mechanism in OMR::DataType that explicitly defines the required register type for each data type. This would separate the concept of a data type from the register class it requires, making the register assignment logic more robust and maintainable.

Benefits

• Eliminates bugs caused by incorrect assumptions about register usage.
• Improves clarity by making register requirements explicit and centralized.
• Supports future extensions, such as new data types that require vector or other specialized registers.
• Simplifies integration with GRA and downstream optimizations that depend on register type.

Impacted Areas

• Global Register Assigner (GRA)
• Code generation for regLoad / regStore nodes
• Optimizations like regDepCopy removal and JProfilingValue

Request for Feedback

Looking for input on feasibility, design considerations, and potential platform-specific implications.

Tagging @gita-omr, @hzongaro, @r30shah for thoughts.

[ehsankianifar]

Another PR related to data types: #8044

[ehsankianifar]

This spot in code need to properly handle other data types like masks on different platforms:

omr/compiler/codegen/OMRLinkage.cpp

Line 49 in fcdd0f4

else if (argumentNode->getOpCode().isVectorResult())

[ehsankianifar]

several spots in LocalOpts class are using isVectorResult() but it should properly handle all types including masks!
e.g.

omr/compiler/optimizer/LocalOpts.cpp

Line 4280 in fcdd0f4

} else if (node->getOpCode().isVectorResult()) {