On Fri, 25 Oct 2024 22:20:00 GMT, Vladimir Ivanov <vliva...@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
