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

[Jatin Bhateja]

On Tue, 4 Apr 2023 09:49:28 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> @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.
>
>> 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.
> 
> May I know the penalty which you see if we do this as a separate pass towards the end of _PhaseIdealLoop::build_and_optimize_, where we can iterate over __ltree_root_ and for each counted loop marked as a vector loop we can do this processing for all the reduction nodes part of loop body.

There is also an opportunity to support reduction involving non-commutative bytecodes like isub and lsub, but it may need explicit backend support and can be taken up separately.

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

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