[Bug target/43703] Unexpected floating point precision loss due to ARM NEON autovectorization

[siarhei dot siamashka at gmail dot com]

------- Comment #2 from siarhei dot siamashka at gmail dot com  2010-04-09 20:34 -------
(In reply to comment #1)
> This is exacted really.  Denormals are a weird case in general.

Well, denormals may be weird. But what about nan's, inf's and the other IEEE
stuff, which is not supported by NEON unit? The compiler here takes the liberty
of using NEON whenever it likes, and NEON does not fully support IEEE for sure.
After reading man gcc, I had an impression that this should have been
controlled by -ffast-math and the related options.

Floating point performance of VFP Lite unit is a disaster, and using NEON where
appropriate is definitely needed. But IMHO this should be controlled somehow.
For example by selectively using pragma optimize to set -ffast-math option in
the critical parts of code.

Also I don't know how fantastic it is, but having a special data type,
something like 'fast_float' with the relaxed precision requirements and
suitable for use with NEON would be really nice.

> Plus your testcase depends on uninitialized values.

Yes, the testcase is not quite clean, but is easily fixable. Though this should
not cause any problems unless floating point exceptions are enabled, those
extra values are just irrelevant. Should I post an updated testcase?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43703