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.
Ok, this makes the PR easier to review.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/32095#issuecomment-5291316749
