Page MenuHomePhabricator

[compiler-rt] [test] Use approximate comparison on float types
AbandonedPublic

Authored by mgorny on Jan 18 2017, 8:22 AM.

Details

Summary

Use approximate comparison between the result of __divsc3()
and the canonical value calculated, to allow the possible difference of
1 representable value resulting from optimization.

For example, the value of (0.000001+j0.000001) / (-0.500000-j2.000000))
computed the canonical way without specific machine flags is:

z = -0x1.3bce70p-21 + j0x1.7af7bcp-22

However, if -march=i386 -mfpmath=387 is used, it becomes:

z = -0x1.3bce72p-21 + j0x1.7af7bcp-22

While this difference is insignificant, it may cause the exact
comparison used in tests to fail. Allowing the difference of one
representable value seems to be a reasonable compromise.

Diff Detail

Event Timeline

mgorny created this revision.Jan 18 2017, 8:22 AM
compnerd edited edge metadata.Jan 18 2017, 6:49 PM

I think that the checks should be exact. Instead, we should check the compilation mode and change the exact value (i.e. if we are using i387 mode, we would use the adjusted value).

Just to be clear, the values also differ per -O0 vs -O2. I'm not sure if we can even reliably figure that out.

I've tried to work around the issue by building everything in 387 mode. However, in that case muldc3_test has even larger mismatches and didn't really want to go figuring that out.

scanon edited edge metadata.Jan 19 2017, 7:01 AM

These tests should either be exact, or should have a tolerance that's mathematically sound. +/-1ulp is not sound; the allowed error should be proportional to the magnitude of the larger of the real and imaginary components of the result -- e.g. if one component is very small compared to the other, the smaller one may have *no* "correct" bits and still be acceptable.

mgorny abandoned this revision.Feb 15 2017, 2:35 AM

I've opened http://bugs.llvm.org/show_bug.cgi?id=31964 to track this further. I don't really have time to look into it in more detail at the moment.