On 24 October 2011 15:02, Joseph S. Myers <jos...@codesourcery.com> wrote:
> On Mon, 24 Oct 2011, Dmitry Plotnikov wrote:
>
>> * neon.md (floatv2siv2sf2): New.
>> (floatunsv2siv2sf2): New.
>
>> (floatv4siv4sf2): New.
>> (floatunsv4siv4sf2): New.
>
> My undertstanding is that the NEON conversions of integer vectors to
> floating point always round to nearest - so do these patterns need to be
> conditioned on !flag_rounding_math?
That is correct - they round towards nearest if converting from
integer to floating point and round towards zero if converting in the
reverse direction. !flag_rounding_math should be the case at the very
least. I'm not yet convinced that you can get away without a check for
flag_unsafe_math_optimizations because at the very least input
denormals are flushed to zero and hence the inexact bits won't be set.
Thus are we completely compliant when we allow this by default ?
Dmitry :
The testcases shouldn't be adding mfpu=neon etc.
> +/* { dg-options "-O2 -mfpu=neon -mfloat-abi=softfp -ftree-vectorize
> -fdump-tree-vect-details" } */
Instead you should be doing -
/* { dg-require-effective-target arm_neon_ok } */
/* { dg-options "-O2 -ftree-vectorize" } */
/* { dg-add-options arm_neon } */
cheers
Ramana
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
>
