[LLVMbugs] [Bug 15545] New: MultiSource/Benchmarks/TSVC/Reductions-flt tests beyond FLT_MIN

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=15545

            Bug ID: 15545
           Summary: MultiSource/Benchmarks/TSVC/Reductions-flt tests
                    beyond FLT_MIN
           Product: Test Suite
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Nightly Tester
          Assignee: unassignedbugs at nondot.org
          Reporter: renato.golin at linaro.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10204
  --> http://llvm.org/bugs/attachment.cgi?id=10204&action=edit
TSVC's s317 test case

A reduced test case (attached) shows that TSVC is testing beyond the FLT_MIN
(1.7e-38):

S317     0.00         7.0065e-44 

While VFP's VMUL.f32 and the SSE/AVX equivalent do go beyond the limit (I
believe, to be IEEE consistent), NEON's VMUL.f32 does not:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473c/CJAJBEAF.html

Most of the time, flush-to-zero is desired (and it is enabled by default on
Cortex-A5/8 and Swift), but not always. Since A8 is the default target for the
triple "armv7a-*", simple runs of LNT fail on any ARMv7 target.

I have "fixed" it by forcing -mcpu=cortex-a15 on ARM's LNT bot, but it will
still fail on A8.

Question is:

 - Is this not-a-problem (tm) and we just need to disable the NEONFP flag when
running LNT on cortex-A8?
 - Or is this a problem (maybe other archs) and we need to stop when the loop
is getting close to FLT_MIN in that particular case?

I'm fine with either solution, but would like to register the problem, so that
other people don't have to dig through layers of code to find out it was simple
in the end. ;)

I'll open another bug on ARM lowering to make sure we want to use NEON FP32
even when unsafe maths is disable.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130319/71fb6b86/attachment.html>