RFR: 8324890: C2 SuperWord: refactor out VLoop, make unrolling_analysis static, remove init/reset mechanism

Emanuel Peter epeter at openjdk.org
Tue Jan 30 12:18:51 UTC 2024


On Tue, 30 Jan 2024 08:55:24 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Subtask of https://github.com/openjdk/jdk/pull/16620
>> 
>> 1. Move out the shared code between `SuperWord::SLP_extract` (where we do vectorization) and `SuperWord::unrolling_analysis`, and move it to a new class `VLoop`. This allows us to decouple `unrolling_analysis` from the SuperWord object, and we can make it static.
>> 2. So far, SuperWord was reused for all loops in a compilation, and then "reset" (with `SuperWord::init`) for every loop. This is a bit of a nasty pattern. I now make a new `VLoop` and a new `SuperWord` object per loop.
>> 3. Since we now make more `SuperWord` objects, we allocate the internal data structures more often. Therefore, I now pre-allocate/reserve sufficient space on initialization.
>> 
>> Side-note about https://github.com/openjdk/jdk/pull/17604:
>> I would like to remove the use of `SuperWord::is_marked_reduction` from `SuperWord::unrolling_analysis`. For starters: it is not clear what it was ever good for. Second: it requires us to do reduction marking/analysis before `unrolling_analysis`, and hence makes the reduction marking shared between `unrolling_analysis` and vectorization. I could move the reduction marking to `VLoop` now. But the `_loop_reducitons` set would have to be put on an arena, and I would like to avoid creating an arena for the `unrolling_analysis`. Plus, it would just be nicer code, to have reduction analysis together with body analysis, type analysis, etc. and all of them in only in `SLP_extract`.
>
> src/hotspot/share/opto/superword.cpp line 75:
> 
>> 73: 
>> 74: //------------------------------transform_loop---------------------------
>> 75: bool SuperWord::transform_loop(IdealLoopTree* lpt, bool do_optimization) {
> 
> Note: code moved to `VLoop::check_preconditions_helper`

Note: all the `do_optimization` parts are not part of preconditions, and hence they are kept in the new `transform_loop`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17624#discussion_r1470803554


More information about the hotspot-compiler-dev mailing list