RFR: 8302652: [SuperWord] Reduction should happen after loop, when possible

[Emanuel Peter]

On Thu, 30 Mar 2023 07:55:28 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/superword.cpp line 2890:
>> 
>>> 2888:     UnorderedReductionNode* ur = unordered_reductions.at(i)->as_UnorderedReduction();
>>> 2889:     move_unordered_reduction_out_of_loop(ur);
>>> 2890:   }
>> 
>> Hi @eme64 , if we move this processing post SLP to a stand alone pass, we can also handler vector IR created through VectorAPI.
>
> We can also relax following limitation with your patch since loop body will now comprise of lane wise vector operations with reduction moved out of loop it may allow vectorizing  patterns like  res += a[i];  which is composed of single load and reduction operation, unrolling will create multiple vector operations within loop may improve performance.
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/superword.cpp#L2265

@jatin-bhateja 

> if we move this processing post SLP to a stand alone pass, we can also handler vector IR created through VectorAPI.

Where exactly would you put it? We need a location during LoopOpts, so that we have the ctrl information. I previously suggested in `split_if`, but @vnkozlov seemed not very excited. Additionally, I have not seen any case where VectorAPI could make use of it. I gave it a quick look, so maybe you can find something.

Maybe in the long run, we should have a node-by-node pass during loop-opts, and allow all sorts of peep-hole optimizations that require ctrl/idom information. We already have a number of non-split-if optimizations that have snuck into the `split_if` code. Maybe a refactoring would be a good idea there. What do you think?

And about:
https://github.com/openjdk/jdk/blob/941a7ac7dab243c6033a78880fd31faa803e62ab/src/hotspot/share/opto/superword.cpp#L2265

Yes, that is the hope, that we could allow things like that to vectorize. The question is if we can guarantee that my new optimization will happen. But probably it is ok to be a bit optimistic here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13056#discussion_r1153134345