linux-kernel - Re: [RESEND PATCH] arm64: v8.4: Support for new floating point multiplication variant

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 12 Dec 2017 10:07:21 +0800
From:   gengdongjiu <gengdongjiu@...wei.com>
To:     Suzuki K Poulose <suzuki.poulose@....com>,
        Dave Martin <Dave.Martin@....com>
CC:     Mark Rutland <Mark.Rutland@....com>,
        "guohanjun@...wei.com" <guohanjun@...wei.com>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        Catalin Marinas <Catalin.Marinas@....com>,
        "corbet@....net" <corbet@....net>,
        Will Deacon <Will.Deacon@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linuxarm@...wei.com" <linuxarm@...wei.com>,
        "zhihui.gao@...wei.com" <zhihui.gao@...wei.com>,
        "huangshaoyu@...wei.com" <huangshaoyu@...wei.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "arvind.yadav.cs@...il.com" <arvind.yadav.cs@...il.com>,
        Robin Murphy <Robin.Murphy@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "zhanghaibin7@...wei.com" <zhanghaibin7@...wei.com>, <nd@....com>
Subject: Re: [RESEND PATCH] arm64: v8.4: Support for new floating point
 multiplication variant

On 2017/12/12 2:58, Suzuki K Poulose wrote:
> Hi gengdongjiu
> 
> Sorry for the late response. I have a similar patch to add the support for "FHM", which I was about to post it this week.
Suzuki, you are welcome.
May be you can not post again to avoid the duplicate review, thanks!

> 
> On 11/12/17 13:29, Dave Martin wrote:
>> On Mon, Dec 11, 2017 at 08:47:00PM +0800, gengdongjiu wrote:
>>>
>>> On 2017/12/11 19:59, Dave P Martin wrote:
>>>> On Sat, Dec 09, 2017 at 03:28:42PM +0000, Dongjiu Geng wrote:
>>>>> ARM v8.4 extensions include support for new floating point
>>>>> multiplication variant instructions to the AArch64 SIMD
>>>>
>>>> Do we have any human-readable description of what the new instructions
>>>> do?
>>>>
>>>> Since the v8.4 spec itself only describes these as "New Floating
>>>> Point Multiplication Variant", I wonder what "FHM" actually stands
>>>> for.
>>> Thanks for the point out.
>>> In fact, this feature only adds two instructions:
>>> FP16 * FP16 + FP32
>>> FP16 * FP16 - FP32
>>>
>>> The spec call this bit to ID_AA64ISAR0_EL1.FHM, I do not know why it
>>> will call "FHM", I  think call it "FMLXL" may be better, which can
>>> stand for FMLAL/FMLSL instructions.
>>
>> Although "FHM" is cryptic, I think it makes sense to keep this as "FHM"
>> to match the ISAR0 field name -- we've tended to follow this policy
>> for other extension names unless there's a much better or more obvious
>> name available.
>>
>> For "FMLXL", new instructions might be added in the future that match
>> the same pattern, and then "FMLXL" could become ambiguous.  So maybe
>> this is not the best choice.
> 
> I think the FHM stands for "FP Half precision Multiplication instructions". I vote for keeping the feature bit in sync with the register bit definition. i.e, FHM.
 agree with you

> 
> However, my version of the patch names the HWCAP bit "asimdfml", following the compiler name for the feature option "fp16fml", which
> is not perfect either. I think FHM is the safe option here.
yes, "FHM" is safe here.

> 
>>
>>>> Maybe something like "widening half-precision floating-point multiply
>>>> accumulate" is acceptable wording consistent with the existing
>>>> architecture, but I just made that up, so it's not official ;)
>>>
>>> how about something like "performing a multiplication of each FP16
>>> element of one vector with the corresponding FP16 element of a second
>>> vector, and to add or subtract this without an intermediate rounding
>>> to the corresponding FP32 element in a third vector."?
>>
>> We could have that, I guess.
>>
> 
> I agree, and that matches the feature description.
Ok, thanks!

> 
>