[aarch64-port-dev ] [PATCH] 8217561 : X86: Add floating-point Math.min/max intrinsics, approval request

[Andrew Dinn]

On 06/03/2019 02:05, Pengfei Li (Arm Technology China) wrote:
> Hi Andrew Dinn,
> 
>> What seems very odd to me is the difference between fmaxv and
>> fminv. Both Q == 1 encodings (i.e. with sz in {0, 1}) are reserved
>> for fmaxv. However, the encoding for fminv accepts both Q == 1
>> encodings with the expected interpretation.
> 
> In the latest published version of the ArmARM doc, I don't see such
> difference between fmaxv and fminv. I guess what you have seen might
> be a bug of the previous version docs.

Ok, I'm not sure what documentation you are looking at so I need to
explain where I am getting my information. Up until today I have been
using the Arm ARM C.a which is dated 20 December 2017. I just downloaded
and checked the Arm ARM D.a dated 31 October 2018 which i think is the
latest version. It shows the same difference between fmaxv and fminv in
the same section of the manual.

Looking at the 2018 manual (D.a) the details are on pages C7-1501
onwards. For fmaxv it says under this heading:

  Single-precision and double-precision variant

  . . .

  Decode for this encoding
  integer d = UInt(Rd);
  integer n = UInt(Rn);
  if sz:Q != '01' then UNDEFINED;
  integer esize = 32 << UInt(sz);
  integer datasize = if Q == '1' then 128 else 64;

  . . .

and then on page C7-1502 it says

  <T>
    . . .
   For the single-precision and double-precision variant: is an
arrangement specifier, encoded in the "Q:sz" field. It can have the
following values:
    4S     when Q = 1 , sz = 0
    The following encodings are reserved:
    • Q = 0 , sz = x .
    • Q = 1 , sz = 1 .

However, for fminv on page C7-1502 it says under the following heading

  Single-precision and double-precision variant

  Decode for this encoding
  integer d = UInt(Rd);
  integer n = UInt(Rn);
  integer m = UInt(Rm);
  if sz:Q == '10' then UNDEFINED;
  integer esize = 32 << UInt(sz);
  integer datasize = if Q == '1' then 128 else 64;
  integer elements = datasize DIV esize;

and later on page C7-1503 it says

  <T>
    . . .
    For the single-precision and double-precision variant: is an
arrangement specifier, encoded in the "sz:Q" field. It can have the
following values:
    2S     when sz = 0 , Q = 0
    4S     when sz = 0 , Q = 1
    2D     when sz = 1 , Q = 1
    The encoding sz = 1 , Q = 0 is reserved.

Do you have a later version of the manual than D.a? If not, are you
looking at some other part of the manual? Note that the first decode is
undefined if sz:Q != '01' and the second is UNDEFINED if sz:Q == '01'.

>> Yes, I think it would probably be better to leave the assert in
>> place and use the encoding implied by the SIMD_Arrangement
>> parameter i.e. T2S ==> Q=1,sz=0 and T2D ==> Q=1, sz=1. That way the
>> assert will catch errors in debug builds and non-debug builds
>> should be stopped by a SIGILL exception.
> 
> Thanks, I will do this and post a new webrev in a new thread then.

Ok, thank you.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander