RFR: 8367611: Enable vblendvp[sd] on Future ECore [v3]

[Vladimir Ivanov]

On Fri, 19 Sep 2025 21:57:30 GMT, Mohamed Issa <missa at openjdk.org> wrote:

>> The upcoming ECore platforms will benefit from using `vblendvps` and `vblendvpd` instructions when the destination register is the same as the source register. This change takes that situation into account.
>> 
>> The JTREG test shown below was used to verify correctness against the [OpenJDK v26-b15](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B15) baseline build. This test frequently calls vblendvps() and vblendvpd() in the macro assembler. On Darkmont and non-Darkmont cores, the right code paths are followed when checking with asserts.
>> 
>> 1. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java`
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Combine boolean flags to avoid ambiguity

The patch itself looks fine, but the way instruction emulation is implemented (as introduced by JDK-8320347) doesn't fit the design well. It does look appealing to abstract away the choice, but it becomes confusing when there's a need to reason about exact code shape. Another consequence is code duplication where both x86.ad and `MacroAssembler::vblendvp[sd]` provide their own emulated versions. 

I suggest to reshape it and extract emulated variant into separate methods leaving `Assembler::vblendvp[sd]` as is. Then, for convenience, `C2_MacroAssembler` can provide new methods which do CPU dispatching or just do dispatching explicitly at call sites in `c2_MacroAssembler_x86.cpp`. Also, it's better to move CPU sensing logic to `VM_Version`, so the checks and code emission logic can be unified across all use sites (in `c2_MacroAssembler_x86.cpp` and `x86.ad`).

I'm fine with addressing it either as part of this PR or as a follow-up enhancement.

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

PR Review: https://git.openjdk.org/jdk/pull/27354#pullrequestreview-3258183895