On i386, Nanojit has two basic modes of operation: SSE, and non-SSE. Non-SSE is for old machines that don’t support SSE instructions. (It might actually be SSE2 instructions, I’m not sure.) My two machines both support SSE and so the non-SSE is never exercised unless I specify the environment variable X86_FORCE_SSE=no. Since this invocation doesn’t exactly roll off the fingertips, I don’t do it often. It’s also easy to mistype, in which case the normal SSE code will be run but I probably won’t notice and so I’m testing something different to what I think I am testing.
I recently committed a patch (bug 516348) that broke the non-SSE mode. (It may have also broken the SSE mode, but in a less obvious way.) Whenever I land a patch that breaks something, I try to work out if I could have avoided the breakage through a better process. In this case I could have, through automation. I now have the following set of aliases and functions in my .bashrc:
alias jstt_prefix="python trace-test/trace-test.py" JSTTARGS32="--no-slow -f -x sunspider/check-date-format-tofte.js" JSTTARGS64="$JSTTARGS32" alias jsdtt32=" jstt_prefix debug32/js $JSTTARGS32" alias jsott32=" jstt_prefix opt32/js $JSTTARGS32" alias jsdtt32b="X86_FORCE_SSE2=no jstt_prefix debug32/js $JSTTARGS32" alias jsott32b="X86_FORCE_SSE2=no jstt_prefix opt32/js $JSTTARGS32" alias jsott64=" jstt_prefix opt64/js $JSTTARGS64" alias jsdtt64=" jstt_prefix debug64/js $JSTTARGS64" function jsatt { if [ -d debug32 ] && [ -d debug64 ] && [ -d opt32 ] && [ -d opt64 ] ; then cd debug32 && mq && cd .. && \ cd debug64 && mq && cd .. && \ cd opt32 && mq && cd .. && \ cd opt64 && mq && cd .. if [ $? -eq 0 ] ; then echo echo "debug32" && jsdtt32 && echo echo "debug32 (no SSE)" && jsdtt32b && echo echo "debug64" && jsdtt64 && echo echo "opt32" && jsott32 && echo echo "opt32 (no SSE)" && jsott32b && echo echo "opt64" && jsott64 && echo fi else echo "missing one of debug32/debug64/opt32/opt64" fi }
The code is boring. For those reading closely, it relies on the fact that I always put different builds in the directories debug32/, opt32/, debug64/, opt64/. And I skip check-data-format-tofte.js because it fails if you’re in a non-US timezone, see bug 515214.
I already had ‘jsdtt32’ et al, each of which tests a single configuration. But now with a single command ‘jsatt’ (which is short for “JavaScript All trace-tests”) I can run the JS trace-tests on 6 different configurations on a single x86-64 machine: 32-bit debug (SSE), 32-bit debug (non-SSE), 64-bit debug, 32-bit optimised (SSE), 32-bit optimised (non-SSE), 64-bit optimised. And it builds them to make sure they’re all up-to-date.
It’s only a small process change for me, but it means that it’s unlikely I will break any of these configurations in the future, or at least, not in a way that shows up in the trace-tests.
2 replies on “Nanojit test coverage”
You might consider gathering some statistics on how many people actually use the non-SSE mode. Why not just not bother JITting on non-SSE processors?
Unfortunately removing the non-SSE support is not viable at the moment. Nanojit is shared with Adobe, and non-SSE support is currently a requirement for them. One day it hopefully won’t be 🙂