Disable the slowest Mozilla Suite tests at lower optimization levels

[gbrail]

Turn off the slowest tests at opt levels -1 and 0. We still run
these tests at opt level 9, which should be enough to test for what they're
actually testing for.

For example, there is a Date test that loops through every hour for a year
and ensures that a Date can be created and not die a horrible death.
I'm not sure that we really need that and we certainly don't need to
test it three times!

[p-bakker]

Don't we need to at least test at -1 (interpreted) and then one of the compiled levels (0 through 9)?

And speaking of those different optLevels for compiled mode: is there actually any difference between them? See #1123

[gbrail]

I will check the code but I think that the only difference is whether the optimizer tries to replace strings of numeric functions with floating-point operations directly in the bytecode, rather than putting Number objects on the stack and calling ScriptRuntime operations to operate on them -- even with floating-point math the direct bytecode is a lot faster. TBH, I'm not convinced that we need all of these MozillaSuiteTests at all, especially that ones that are trying to figure out if GC works badly based on how Java worked 20 years ago, or trying to do things like create a date for every hour in the year. Maybe this is too aggressive a change but I'm not so sure.

[p-bakker]

but I think that the only difference is whether the
optimizer tries to replace strings of numeric functions with floating-point
operations directly in the bytecode

If you figure it out, please let us know (so I can also point to that in the documentation). I wasn't able to find anything previously, whick would mean we could just completely disable running the testsuite for one of the two compiled opt levels

TBH, I'm not convinced that we need all of these MozillaSuiteTests at all

I guess you're talking about specific tests from the testsuite. I've been wondering myself as well, because to my knowledge a fair chunk of this testsuite was shared with SpiderMonkey and those test got rolled into Test262 if I'm not mistaken, so there might be a lot of overlap

[gbrail]

I'm going to close this for now -- I think that we can figure out whether we really need three optimization levels first. Also, I think that we can also get rid of a few of these tests just because they do crazy things like make sure that we can convert every date in a year in a giant slow loop...