On Sun, Oct 16, 2011 at 10:21 PM, Armin Rigo <ar...@tunes.org> wrote: > Hi David, > > On Sun, Oct 16, 2011 at 19:13, David Cournapeau <courn...@gmail.com> wrote: >> (...) and there is also the issue >> of correctness in floating point code generation. Given that >> decade-old compilers get it wrong, I would expect pypy jit to have >> quite a few funky corner cases as well. > > No, we should not have corner cases, because we don't go there at all. > We know very well that rewriting operations on floats can slightly > change their results, so we don't do it. In other words the JIT > produces a sequence of residual operations that has bit-wise the same > effect as the original sequence of Python operations. > > (More precisely, it seems that we only replace FLOAT_MUL(x, 1.0) by > "x" and FLOAT_MUL(x, -1.0) by "-x", as well as simplify repeated > FLOAT_NEG's and assume that FLOAT_MUL's are commutative. As far as I > can tell these trivial optimizations are all bit-wise correct, at > least on modern FPUs.)
Interesting to know. But then, wouldn't this limit the speed gains to be expected from the JIT ? And I am not sure I understand how you can "not go there" if you want to vectorize code to use SIMD instruction sets ? David _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev