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

[Quan Anh Mai]

On Fri, 25 Oct 2024 22:20:00 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>>> Because lowering is a transformation that increases the complexity of the graph.
>>> 
>>> * A `d = ExtractD(z,  4)` expanded into `x = VectorExtract(z, 2); d = ExtractD(x, 0)` increases the number of nodes by 1.
>>> * A logic cone transformed into a `MacroLogicV` introduces another kind of node that may not be recognized by other nodes.
>>> 
>>> As a result, we should do this as the last step when other transformation has finished their jobs. For the concerns regarding loop body size, we still have a function in `Matcher` for that purpose.
>> 
>> Yes, you rightly pointed out, given the fact that lowering in some cases may significantly impact the graph shape it should be accounted by loop optimizations.
>> 
>> Unrolling decisions are  based on loop body size and a rudimentary cost model e.g. macro logic optimization which folds entire logic tree into one x86 specific lowered IR should promote unrolling.
>
>> By allowing lowering to look through VectorReinterpret and break the invariant of Extract nodes that the element types of their inputs and outputs must be the same, we can gvn v1 and v, v2 and v0.
> 
> I'd warn against breaking existing IR invariants. As an example, precise type information is important to properly match generic ideal vector nodes.

I believe the matcher only needs the exact type of the node but not its inputs. E.g. it should not be an issue if we `AddVB` a `vector<int,8>` and a `vector<long,2>` into a `vector<byte,16>`.

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

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