Re: [PATCH 9/17][ARM] Add NEON FP16 arithmetic instructions.

[Joseph Myers <joseph@codesourcery.com>]

On Thu, 19 May 2016, Jiong Wang wrote:

> Then,
> 
>   * if we add scalar HF mode to standard patterns, vector HF modes operation
> will be
>     turned into scalar HF operations instead of scalar SF operations.
> 
>   * if we add vector HF mode to standard patterns, vector HF modes operations
> will
>     generate vector HF instructions directly.
> 
>   Will this still cause precision inconsistence with old gcc when there are
> cascade
>   vector float operations?

I'm not sure inconsistency with old GCC is what's relevant here.

Standard-named RTL patterns have particular semantics.  Those semantics do 
not depend on the target architecture (except where there are target 
macros / hooks to define such dependence).  If you have an instruction 
that matches those target-independent semantics, it should be available 
for the standard-named pattern.  I believe that is the case here, for both 
the scalar and the vector instructions - they have the standard semantics, 
so should be available for the standard patterns.

It is the responsibility of the target-independent parts of the compiler 
to ensure that the RTL generated matches the source code semantics, so 
that providing a standard pattern for an instruction that matches the 
pattern's semantics does not cause any problems regarding source code 
semantics.

That said: if the expander in old GCC is converting a vector HF operation 
into scalar SF operations, I'd expect it also to include a conversion from 
SFmode back to HFmode after those operations, since it will be producing a 
vector HF result.  And that would apply for each individual operation 
expanded.  So I would not expect inconsistency to arise from making direct 
HFmode operations available (given that the semantics of scalar + - * / 
are the same whether you do them directly on HFmode or promote to SFmode, 
do the operation there and then convert the result back to HFmode before 
doing any further operations on it).

-- 
Joseph S. Myers
joseph@codesourcery.com