RFR: 8342662: C2: Add new phase for backend-specific lowering [v6]

Xiaohong Gong xgong at openjdk.org
Wed Jan 15 05:57:49 UTC 2025


On Wed, 15 Jan 2025 02:29:26 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Thanks for the reply!
>> 
>>> lower_node_transform transforms a node that should not appear in matching to something that can appear there while LoweredIdeal transforms a node that may appear in matching to another based on the pattern of its input.
>> 
>> So `lower_node_platform` may do lowering for nodes like macro ones, right? If so, adding `macro` keyword to the function is better to me.  Another question for me: why does it need such separation? For macro nodes, if `LoweredIdeal` cannot match the lowering requirement, we can lowering them during macro expansion, right? 
>> 
>>> So to your question, I think LoweredIdeal would be a better choice, this aligns pretty well with our current method of doing it in Ideal, too.
>> 
>> This makes sense to me and is also what I expected. But consider `LoweredIdeal` is a virtual method on each IR node, how can we do architecture specific transformation in it, except for adding the arch specific hook in matcher? Or do you have a REF change for above `VectorInsert` in `LoweredIdeal` ? Thanks a lot!
>
> I would advise against using the term macro to avoid confusion with PhaseMacroExpansion.
> 
> Regarding the separation, your point about the architecture dependency is the reason why we need a separate lower_node_transform. Suppose you want to lower a machine-independent node on x86. With lower_node_transform we would only need to add a case to the function, while with LoweredIdeal we would need to implement it for all architectures. Note that we can lower a machine-independent node to a machine-dependent node, for example let's imagine a node X86VectorRearrangeConst. So we can write machine-dependent transformation without using machine-dependent code.

OK. I guess I got it more clear. Thanks for the clarifying!

As a summary, this phase may do following transformations:
1. IR Identity   -> backend in-dependent (different with GVN Identity)
2. lowering    -> backend in-dependent
3. lower_node_platform   ->backend dependent
4. IR Ideal     -> backend in-dependent (different with GVN Ideal)

If we want to add backend specific lowering, the only function is `lower_node_platform` in backend file, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21599#discussion_r1915979224


More information about the hotspot-compiler-dev mailing list