RFR: 8340093: C2 SuperWord: implement cost model [v4]
Quan Anh Mai
qamai at openjdk.org
Thu Nov 6 07:27:05 UTC 2025
On Wed, 5 Nov 2025 17:23:35 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:
>> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
>>
>> rename cost methods for Vladimir K
>
> src/hotspot/share/opto/vectorization.cpp line 635:
>
>> 633: // Each reduction is composed of multiple instructions, each estimated with a unit cost.
>> 634: // Linear: shuffle and reduce Recursive: shuffle and reduce
>> 635: float c = requires_strict_order ? 2 * vlen : 2 * exact_log2(vlen);
>
> Can we ask for the cost of the element-wise opcode here, something like `(1 + element_wise_cost)` would be more accurate?
To be a little more precise, the strict one should be something like:
vlen * (1 + Matcher::vector_op_pre_select_sz_estimate(Op_Extract, bt, vlen)) + (vlen - 1) * (1 + Matcher::scalar_op_pre_select_sz_estimate(opcode, bt)));
and the non-strict one would be:
float c = Matcher::vector_op_pre_select_sz_estimate(Op_Extract, bt, 2) * 2 + Matcher::scalar_op_pre_select_sz_estimate(opcode) + 3;
for (int i = 4; i <= vlen; i *= 2) {
c += 2 + Matcher::vector_op_pre_select_sz_estimate(Op_VectorRearrange, bt, i) + Matcher::vector_op_pre_select_sz_estimate(opcode, bt, i);
}
Maybe refactoring a little bit to make the `Matcher::vector_op_pre_select_sz_estimate` less awkward would be welcomed, too. Currently, it returns the estimated size - 1, which is unsettling.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27803#discussion_r2497769367
More information about the hotspot-compiler-dev
mailing list