[PATCH] LNT ARM sqlite3

[Daniel Dunbar]

On Thu, Mar 28, 2013 at 11:33 AM, Renato Golin <rengolin at systemcall.org>wrote:

> On 28 March 2013 18:10, Daniel Dunbar <daniel at zuster.org> wrote:
> > I'm fine with this form of cowardice, as long as the changes can be
> > reasonably expected to not hide a potential correctness bug (and sqlite
> is
> > not a benchmark I anticipate to be the one to expose FP math errors). I
> made
> > a large number of these changes to try and stabilize the output of
> > benchmarks as part of moving to using reference outputs.
>
> The problem with sqlite3 is that the FP math in is is bogus. The code
> abuses of FP precision as if they were real numbers, and that's asking
> for trouble.
>
> For instance, if I round to 5 digits the number 1.55555555, sometimes
> it produces 1.55554999999 which doesn't even make sense. So the
> problem in sqlite3 is not just the FP math, but also how the result is
> converted to strings, which affect the output fidelity.
>

Okay, I'll trust you are on top of this. :)

I seem to recall hitting a similar kind of bug in another benchmark, it is
possible to just change the sqlite code to use a more standard
implementation of the conversion (like sprintf?).

> Please still file the bug with the fpcmp utility, with the two inputs that
> > show the problem.
>
> Will do. I'll try to isolate the issue to fpcmp only.


Thanks!


>
> > One thing I do find a little odd is that all of the tests in the test
> suite
> > pass on ARM on iOS, so I'm a little curious what platform/architecture
> > difference causes you to see this. Any ideas?
>
> SoftFP?
>
> There are other tests (Burg, anagram, lemon) which fail on ARM (hf)
> and on my laptop (x86_64) but coincidentally with the exact same
> output. Anagram seems to be due to qsort being different, so the libc
> version might be the culprit.
>

Makes sense. My preferred fix for those is to augment the input and
comparison routine so the array has a total ordering, which makes it
independent of the actual sort implementation. However, this can also be a
pain.

This is another place where it might be very handy to have a platform
independent runtime library that we could build once and link in to all the
executables, and start accumulating implementations of all the things that
platform dependencies in the program output. Honestly, adding that
shouldn't even be that much work... maybe if I can scratch some time
together...

Do you have a comprehensive list of all the tests that are failing presumed
due to bogus reference output mismatches?

 - Daniel


> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130328/b6e52285/attachment.html>