The ARM_TRADITIONAL back-end should also follow the direction of JSValue development. Here is some performance numbers: SunSpider: sunspider-results-jsc-v7-jsvalue32_64.js : 2134.3 sunspider-results-jsc-v7-jsvalue32.js : 3886.1 (1.821x as slow) V8: sunspider-results-jsc-v7-jsvalue32.js : 14600.2 sunspider-results-jsc-v7-jsvalue32_64.js : 15961.8 (1.093x as slow) WindScorpion: sunspider-results-jsc-v7-jsv32_64.js : 9548.5 sunspider-results-jsc-v7-jsv32.js : 9662.75 (1.012x as slow) So, 2 of the 3 benchmark say the JSValue32_64 is faster. Although the r64319 or r64320 causes 10% performance regression in JSValue32 on ARM (see at http://webkit.sed.hu/benchmark/query/advanced/63695;64541;linux-arm-qt;jit;ss;speed ). So the overall picture is not so clear. ;)
Created attachment 63323 [details] Enable JSValue32_64 on ARM by default
Created attachment 63332 [details] Enable JSValue32_64 for GCC on ARM by default Enable JSValue32_64 only for GCC on ARM. JSValue32_64 will be enabled for RVCT in another patch.
Comment on attachment 63332 [details] Enable JSValue32_64 for GCC on ARM by default r=me
Committed revision 64632.