[LLVMdev] ARM NEON VMUL.f32 issue

Jim Grosbach grosbach at apple.com
Tue Mar 19 14:13:40 PDT 2013

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.


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>

More information about the llvm-dev mailing list