[PATCH] 8217561 : X86: Add floating-point Math.min/max intrinsics
bsrbnd at gmail.com
Sun Feb 3 12:23:09 UTC 2019
On Sat, 2 Feb 2019 at 17:57, Viswanathan, Sandhya
<sandhya.viswanathan at intel.com> wrote:
> Hi Bernard,
> There were two problems in the patch:
> 1) The instruction encoding of 'minpd' and 'maxpd' (it was being encoded as minps, maxps).
> 2) The registers for operands 'a' and 'b' were being swapped but the 'effect' in the instruct only showed it as USE.
> Two alternative here:
> a) Mark the register as USE_KILL but that can only be used on fixed registers (a restriction on register allocator).
> b) Use another temporary register and don’t overwrite 'a' and 'b'.
> So we went with b).
Yes, sorry, I went too quickly:
2849 // Following pseudo code describes the algorithm for max[FD]:
2850 // Min algorithm is on similar lines
2851 // btmp = (b < 0) ? a : b
2852 // atmp = (b < 0) ? b : a
2853 // Tmp = Max_Float( atmp , btmp)
2854 // Res = (atmp == NaN) ? atmp : Tmp
seems good to me.
> We will do the test-tier1 for 32 bit and get back. We will also update the copyright year and maxss, cmpss change in the next update.
> Regarding the test case, it is from Pengfei.Li at arm.com. http://cr.openjdk.java.net/~pli/rfr/8212043/webrev.04 . Andrew Dinn missed pushing it as part of the commit for 8212043.
> It would be better if Pengfei/Andrew push it. I will request them and remove from this patch.
Since the test case may be slightly updated (some parameters),
shouldn't we push it as part of this patch adding a second
'contributed-by' to Pengfei?
> Best Regards,
More information about the hotspot-compiler-dev