Currently, matching complex backend-specific patterns, such as logic cones for MacroLogicV, is done in shared code. In the review of JDK-8341137 another use case came up, where an x86-specific optimization for long multiplication where both operands have the high 32 bits set to zero. Doing such an optimization in shared code means introducing a new backend-specific node to shared code or encoding semantically significant data in an existing node, which can lead to subtle bugs. In the review of JDK-8341137, [~qamai], [~jbhateja], and I discussed a new compiler phase that could subsume these optimizations and provide a framework for new backend-specific node lowerings. The benefit of delegating lowering code to the backend (such as MacroLogicV matching) is reducing the complexity of shared code while also allowing for more in-depth platform specific optimization.

Another example of where this could be used is with the x86 BEXTR instruction, which matches the pattern x & A >> B. This results in a constant operand composed of A and B, but the instruction itself does not have a constant encoded form. Therefore, in the code generation of this instruction it would need to move the constant to a register manually. With this new phase, we could instead convert these patterns into 2 different nodes, a BextrNode and a standard ConINode. This would allow for re-use of constants and let code motion more freely schedule the instructions, which could help in tight loops.

This RFE focuses mainly on creating the skeleton code for the new pass. [~jbhateja] mentioned he would move the MacroLogicV code to this system in a new patch.