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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130319/23b6dc82/attachment.html>
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>
On 19 March 2013 21:13, Jim Grosbach <grosbach at apple.com> wrote:> 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. >Thanks Jim, noted about Darwin, I won't touch it. ;) cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130319/9731ad80/attachment.html>
Hi, | 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? Note that if you go for the second option, IMO unsafe-math is _far_ too "aggressive" an option to control this whether multiplies should be allowed produce denormals. I can imagine plenty of cases where I wouldn't care about denormals, but wouldn't want some of the other fast-math semantics applied. Does llvm/clang have any option like strict-iee754 that users can toggle to control things like this? Cheers, Dave -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130320/5b3b6e85/attachment.html>
Sorry: the occurrence of fast-math is a typo for another unsafe-fp-math. Although unsafe-fp-math is more conservative I still think it's too aggressive for controlling this. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of David Tweed Sent: 20 March 2013 09:58 To: Renato Golin; LLVM Dev Subject: Re: [LLVMdev] ARM NEON VMUL.f32 issue Hi, | 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? Note that if you go for the second option, IMO unsafe-math is _far_ too "aggressive" an option to control this whether multiplies should be allowed produce denormals. I can imagine plenty of cases where I wouldn't care about denormals, but wouldn't want some of the other fast-math semantics applied. Does llvm/clang have any option like strict-iee754 that users can toggle to control things like this? Cheers, Dave -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130320/eb14ae41/attachment.html>