On 21 March 2013 12:57, Ramana Radhakrishnan
wrote:
> This was the reason GCC disabled vectorization for a lot of fp operations
> for neon when in strict IEEE754 conformance mode for the ARM port which is
> the default. And I suspect you want LLVM to as well if it already doesn't :)
>
> http://gcc
> -Original Message-
> From: linaro-toolchain-boun...@lists.linaro.org [mailto:linaro-
> toolchain-boun...@lists.linaro.org] On Behalf Of Mans Rullgard
> Sent: 20 March 2013 14:17
> To: Renato Golin
> Cc: Kristof Beyls; Linaro Toolchain; Tim Northover
> Subje
On 20 March 2013 08:11, Kristof Beyls wrote:
> ยท **Does this result in non-compliance of IEEE754 regarding
> denormals? NaN? INFs? Something else?
>
Yes, but only slightly. ;)
I don't want to treat this question as black and white because the penalty
is severe, but I also don't want pe
On 19 March 2013 21:56, Renato Golin wrote:
> Hi folks,
>
> I found an issue while fixing a test using the wrong VMUL.f32, and I'd like
> to know what should be our choice on this topic that is slightly
> controversial.
>
> Basically, LLVM chooses to lower single-precision FMUL to NEON's VMUL.f32
On 19 March 2013 21:56, Renato Golin wrote:
> Basically, LLVM chooses to lower single-precision FMUL to NEON's VMUL.f32
> instead of VFP's version because, on some cores (A8, A5 and Apple's Swift),
> the VFP variant is really slow.
>
> This is all cool and dandy, but NEON is not IEEE 754 compliant
Hi Renato,
I think to be able to make the best possible judgement here, answers to the
following questions would be needed:
* Does this result in non-compliance of IEEE754 regarding denormals?
NaN? INFs? Something else?
* Also, does the C/C++ standard say something about IEEE
