[LLVMdev] ARM NEON VMUL.f32 issue

[Jim Grosbach]

Hi Renato,

You're right. Strictly speaking, using NEON for scalar floating point isn't completely safe for exactly this reason (also NaNs, IIRC). We generally do it anyway because on common cores (cortex-a8) VFP is pretty terrible and the NEON approximation is correct for the vast majority of use-cases that people care about. Yes, that's cutting some corners. Would you mind making this change depend on platform? Darwin should continue to use NEON by default for these operations.

-Jim

On Mar 19, 2013, at 11:17 AM, Renato Golin <renato.golin at linaro.org> wrote:

> Hi folks,
> 
> I just "fixed" a bug on ARM LNT regarding lowering of a VMUL.f32 as NEON and not VFP. The former is not IEEE 754 compliant, while the latter is, and that was failing TSVC.
> 
> The question is:
>  * is this a problem with the test, that shouldn't be expecting values below FLT_MIN, or
>  * is it a bug in the lowering, that should only be lowering to NEON's VMUL when unsafe-math is on, or
>  * neither, and people should disable that when they want correctness?
> 
> The bugs in question...
> 
> Possible unsafe maths bug in NEON VMUL.f32
> http://llvm.org/bugs/show_bug.cgi?id=15546
> 
> MultiSource/Benchmarks/TSVC/Reductions-flt tests beyond FLT_MIN
> http://llvm.org/bugs/show_bug.cgi?id=15545
> 
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130319/b55e36ab/attachment.html>