[LLVMbugs] [Bug 11183] New: Compiler optimized neon vector comparison result differs from result obtained at runtime

[bugzilla-daemon at llvm.org]

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

           Summary: Compiler optimized neon vector comparison result
                    differs from result obtained at runtime
           Product: tools
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dcope.public at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I am using llvm-gcc on MacOS X.  I am using gcc version 4.2.1 (LLVM build
2377).  I am cross compiling for an ARM iOS device with neon instruction
support enabled.  (I can provide detailed compiler command line options if
required.)

It appears that in optimized builds the compiler is examining some constants in
my program and then eliminating some calculations (i.e. it precomputes the
result of a sequence of operation and prints out a constant value).  This
optimization would be fine, but the result of this comparison does not match
the result that would have been generated at runtime on the target.

Here is some sample code that demonstrates the problem.


#include <stdio.h>
#include <string.h>
#include <arm_neon.h>


volatile float32x4_t temp = { 1e-040f, 1e-040f, 1e-040f, 1e-040f };

int main(int argc, char**argv)
{
//#define COMPILER_UNKNOWN_CONSTANT
#ifdef COMPILER_UNKNOWN_CONSTANT
    float32x4_t smallValue;
    memcpy(&smallValue, (void*)&temp, sizeof(temp));
#else
    float32x4_t smallValue = { 1e-040f, 1e-040f, 1e-040f, 1e-040f };
#endif
    float32x4_t zero = { 0.0f, 0.0f, 0.0f, 0.0f };
    uint32x4_t compare = vceqq_f32(smallValue, zero);
    printf("compare result is 0x%x\n", vgetq_lane_u32(compare, 0));

    return 0;
}


In an optimized build (-O3) this code will print out 0x0.  However in a debug
build the program will output 0xffffffff.  The program will also output
0xffffffff in optimized builds if smallValue's value can't be determined by the
compiler at compile time (i.e. by defining COMPILER_UNKNOWN_CONSTANT).

>From what I understand, the compiler is allowed to pre-compute the result of a
calculation, but that value should match the value that would be computed at
runtime on the target platform.

So, I believe that the test should be printing out 0xffffff in all cases.

I have also encountered this issue when using clang to compile similar code, so
I believe the root of the problem is actually in the LLVM backend.  However I
decided to submit this bug under llvm-gcc since I haven't verified that is the
case.

Is this in fact a bug in LLVM as I suspect, or is the compiler's generated code
actually correct in this situation?

Thanks,
Dave

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.