[PATCH] LNT ARM sqlite3

[Daniel Dunbar]

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

> On 28 March 2013 18:45, Daniel Dunbar <daniel at zuster.org> wrote:
> > 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?).
>
> I tried, but vxprintf (the local version of vprintf) has a context
> passed in, which gets changed many times in many different branch
> options throughout the execution of vxprintf.
>
> I did try calling sprintf on the context buffer, but that wasn't
> enough. I also tried saving the double value into a temporary variable
> and re-use it in the end (avoiding most of the FP madness), but that
> incurred in the rounding issues I said earlier.
>
>
> > 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.
>
> On all those examples, the input and the search space are both too
> big. I thought about using a stable sort instead of qsort, but haven't
> tried it yet.
>

I don't understand this comment. I just meant transforming the call to
qsort so the sort would be stable, regardless of the actual sort
implantation, by augmenting the comparator function with the index of the
element in the incoming array (to disambiguate equality). See also
http://en.wikipedia.org/wiki/Schwartzian_transform


> On anagram, the main issue is that the sort order is not direct, but
> depends on the current value of an array indexed by the element, which
> makes matters more complex.
>
>
> > 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...
>
> The RNG implementation I've added to the other three tests could be a
> good start. Though you might find it hard to get it working on every
> platform variant, as much as other library writers... ;)
>
>
> > Do you have a comprehensive list of all the tests that are failing
> presumed
> > due to bogus reference output mismatches?
>
> Yes!
>
>   - Failing on both ARM and Intel, exact same output
>     + MultiSource/Applications/Burg/burg
>     + MultiSource/Applications/lemon/lemon
>     + MultiSource/Benchmarks/Ptrdist/anagram/anagram
>
>  - Failing on both ARM and Intel, different output
>     + MultiSource/Applications/ClamAV/clamscan
>
>  - Failing only on Intel:
>     + MultiSource/Benchmarks/Olden/voronoi
>
>  - Failing only on ARM:
>     + MultiSource/Applications/sqlite3
>
>  - With:
>     + ARM: Chromebook Cortex-A15 hardfloat
>     + Intel: x86_64 core i7
>
> I can send you the Output directory of them all if you want (it's
> about 5M, so I won't copy the list).
>

I don't think that would help me much without being able to run them to
understand the differences. The clamscan and voronoi failures sound
familiar to me, from when I tried to get reference inputs tidied up on
Linux, but I've forgotten the details.

If I get some time to look at this I'll just find a Linux environment to
use to investigate, which should cover all the issues except for the
sqlite3 one.

 - Daniel


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