Re: [PATCH 8/17][ARM] Add VFP FP16 arithmetic instructions.

[Matthew Wahab <matthew.wahab@foss.arm.com>]

On 03/08/16 12:52, Ramana Radhakrishnan wrote:
> On Thu, Jul 28, 2016 at 12:37 PM, Ramana Radhakrishnan
> <ramana.gcc@googlemail.com> wrote:
>> On Mon, Jul 4, 2016 at 3:02 PM, Matthew Wahab
>> <matthew.wahab@foss.arm.com> wrote:
>>> On 19/05/16 15:54, Matthew Wahab wrote:
>>>> On 18/05/16 16:20, Joseph Myers wrote:
>>>>> On Wed, 18 May 2016, Matthew Wahab wrote:
>>>>>
>>>>> In short: instructions for direct HFmode arithmetic should be described
>>>>> with patterns with the standard names.  It's the job of the
>>>>> architecture-independent compiler to ensure that fp16 arithmetic in the
>>>>> user's source code only generates direct fp16 arithmetic in GIMPLE (and
>>>>> thus ends up using those patterns) if that is a correct representation of
>>>>> the source code's semantics according to ACLE.
>>>>>
>>>
>>> This patch changes the implementation to use the standard names for the
>>> HFmode arithmetic. Later patches will also be updated to use the
>>> arithmetic operators where appropriate.
>>>
>>
>> All fine except -
>>
>> Why can we not extend the <vrint_pattern> and the l<vrint_pattern> in
>> vfp.md for fp16 and avoid all the unspecs for vcvta and vrnd*
>> instructions ?
>>
>
> I now feel reasonably convinced that these can go away and be replaced
> by extending the <vrint_pattern> and l<vrint_pattern> expanders to
> consider FP16 as well. Given that we are still only in the middle of
> stage1 - I'm ok for you to apply this as is and then follow-up with a
> patch that gets rid of the UNSPECs . If this holds for add, sub and
> other patterns I don't see why it wouldn't hold for all these patterns
> as well.
>
> Joseph, do you have any opinions on whether we should be extending the
> standard pattern names or not for btrunc, ceil, round, floor,
> nearbyint, rint, lround, lfloor and lceil optabs for the HFmode
> quantities ?
>

Sorry for the delay replying.

I didn't extend the lvrint_pattern and vrint_pattern expanders to HF mode 
because of the general intention to do fp16 operations through the NEON 
intrinsics. If extending them to HF mode  produces the expected behaviour for 
the standard names that they implement then I agree that the change should be made.

I would prefer to do that as a separate patch though, to make sure that the new 
operations are properly tested. Some of the existing tests (in gcc.target/arm) 
use builtins that aren't available for HF mode so something else will be needed.

Matthew