On 21 June 2018 at 02:53, Richard Henderson
<richard.hender...@linaro.org> wrote:
> Signed-off-by: Richard Henderson <richard.hender...@linaro.org>
> ---
> target/arm/helper-sve.h | 13 +++++++++++++
> target/arm/sve_helper.c | 27 +++++++++++++++++++++++++++
> target/arm/translate-sve.c | 30 ++++++++++++++++++++++++++++++
> target/arm/sve.decode | 8 ++++++++
> 4 files changed, 78 insertions(+)
> +static inline float32 sve_f16_to_f32(float16 f, float_status *s)
> +{
> + return float16_to_float32(f, true, s);
> +}
> +
> +static inline float64 sve_f16_to_f64(float16 f, float_status *s)
> +{
> + return float16_to_float64(f, true, s);
> +}
> +
> +static inline float16 sve_f32_to_f16(float32 f, float_status *s)
> +{
> + return float32_to_float16(f, true, s);
> +}
> +
> +static inline float16 sve_f64_to_f16(float64 f, float_status *s)
> +{
> + return float64_to_float16(f, true, s);
> +}
A comment to the effect that the SVE fp-to-fp conversion
routines always use IEEE format halfprec (ie ignore FPCR.AHP)
would be helpful.
Are you sure we have the FPCR.FZ16 handling right here? That
is, do we need the same "use the not-fp16 fpstatus pointer,
and temporarily clear the flush flag for the fp16 end of
the conversion" behaviour that we have in vfp_fcvt_f16_to_f32
and friends ? The pseudocode FPConvertSVE() calls FPConvert(),
which is the "ignore FZ16" codepath I think. The test case would
be (eg) a conversion where the input f16 is denormal and
FPCR.FZ == 1: this should not do the flush-input-to-zero, right?
thanks
-- PMM
