JDK-8340093 layed the foundations of cost modeling auto vectorization, but uses a very simplistic unit cost per instruction approach.

[~qamai] Had an idea here:
https://github.com/openjdk/jdk/pull/27803#discussion_r2495478951
We could use Matcher::vector_op_pre_select_sz_estimate and Matcher::scalar_op_pre_select_sz_estimate.

It is not clear to me yet that counting instructions is the best we can do, since not all instructions have the exact throughput and latency impact. We may also have to invest in measuring performance on various platforms and estimating cost empirically. But that has a huge complexity, which first would have to prove helpful.

Suggested approach: we first need to find a set of benchmarks where the cost model is inaccurate, and then see what approach would fix those benchmarks. We should attach such reports to this issue here. For now, there may be no case yet where the cost model is inaccurate, but as we rely more and more on it (with pack/extract/shuffle/if-conversion), there may be more and more cases where we discover a better cost model would be helpful.