RFR: 8349138: Optimize Math.copySign API for Intel e-core targets [v2]

[Jatin Bhateja]

On Tue, 4 Feb 2025 06:14:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Could you instead do this by trying to transform `AndI(MoveF2I(x), MoveF2I(y))` into `AndF(x, y)` instead?
>
>> Could you instead do this by trying to transform `AndI(MoveF2I(x), MoveF2I(y))` into `AndF(x, y)` instead?
> 
> @merykitty , this patch does not break existing IR invariants as multiple targets already emit efficient instruction sequences for it, we have just improved upon the x86-backed implementation.
> ![image](https://github.com/user-attachments/assets/61845793-ca3a-4ad2-8ee8-210f8a1bc60d)
> 
> 
> Introducing another new IR "AndF" will again need changes in auto-vectorizer.

> @jatin-bhateja Doing the transformation to `AndF` would be a more general solution and thus better.
> 
> > Introducing another new IR "AndF" will again need changes in auto-vectorizer.
> 
> But currently, `CopySign` and `MoveF2I` are not vectorized anyway so we can do the vectorization of `AndF` in a separate patch without much hassle. `AndF` is vectorized into existing `AndV` nicely so it is not a too complicated work.

Yes, I have a follow-up patch to auto-vectorized CopySign.

> > this patch does not break existing IR invariants
> 
> Also, what invariant can be broken by transforming `AndI(MoveF2I(x), MoveF2I(y)` into `MoveF2I(AndF(x, y))`?

Hi @merykitty ,  I meant that in the context of CopySign, targets emit efficient instruction sequences for existing IR (CopySignF/D),  this patch simply tuned x86 backend implementation to improve performance.

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

PR Comment: https://git.openjdk.org/jdk/pull/23386#issuecomment-2634649969