On Fri, 14 Aug 2026 04:15:11 GMT, Eric Fang <[email protected]> wrote:
>> @erifan Thanks for your response. The issue I see is that there are a lot of
>> different patterns, and each time we will just say well we only want to
>> focus on vector/mask canonicalization. And with more patterns getting
>> integrated, it will take us more work to consolidate the implementations
>> between the vector nodes and the scalar nodes.
>>
>> My idea is that we will have a utility object `ArithmeticPattern` (for
>> example) which can be constructed from an arithmetic node. The object will
>> know what the element type is, how to create a constant, how to check
>> whether a node is a constant, or if it is a particular constant. With
>> template, the checks can be much easier. For example (you can probably think
>> of a better way, this is just my first thought):
>>
>> enum class NodeTypeCon {
>> INT,
>> LONG,
>> VECTOR
>> }
>>
>> template <class NodeClass>
>> class NodeType;
>>
>> template<>
>> class NodeType<XorINode> {
>> static constexpr NodeTypeCon value = INT;
>> };
>>
>> template <NodeTypeCon nodeType>
>> Node* create_xor(Node* op1, Node op2);
>>
>> template <>
>> Node* create_xor<NodeTypeCon::INT>(Node* op1, Node op2) {
>> return new XorINode(op1, op2);
>> }
>>
>> This will allow us to extend these transformations easier across different
>> data types, and reduce the work to implement more pattern for vector/mask
>> nodes in the future.
>
> Hi @merykitty, thanks for the suggestion — I agree it is reasonable.
>
> Would you prefer that we expand this PR’s scope to also cover the scalar side
> (`XorI` / `XorL`), or keep the current focus on vector and vector mask only?
>
> @dean-long @theRealAph, what do you think?
@erifan You don't need to actually include the scalar side in this PR, but
please structure this PR so that the infrastructure is ready for us to easily
use for the scalar nodes.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/32095#issuecomment-5290837070
