Make sure that on x86 we don't generate SSE2 code in the snapshot.

Make sure that on x86 we don't generate SSE2 code in the snapshot.


BUG=

Committed: https://code.google.com/p/v8/source/detail?r=13844

[mvstanton, 2013-03-01 14:33:43]

Hi Michael,
Here is the change to make sure that we don't generate SSE/floating point reg
code in the snapshot. Note that we do something special for the
StoreBufferOverflowStub. On x86, an extra call at isolate init time will
pregenerate stubs that save FP regs.

[mvstanton, 2013-03-01 17:10:17]

Okay, this one is ready for a look, thanks!

[Sven Panne, 2013-03-04 08:38:19]

General comment: I don't really like the tests for Serializer::Enabled() in this
CL, although they may be semantically correct. What we *really* want to test are
the allowed CPU features (which are partially implied by the Serializer state).

[mvstanton, 2013-03-06 09:32:42]

Here is the updated CL. Sven, note that I removed the "force" feature test, just
relying on CpuFeatures::IsSupported() to work at snapshot time.

[mvstanton, 2013-03-06 13:17:52]

Hi Sven, hi Michael,
I eliminated the TryForce classes and use the new IsSafeForSnapshot() predicate.

Sven, perhaps you should review it?
Thanks for all the help thus far!
--Michael

[Sven Panne, 2013-03-06 13:24:41]

LGTM, but perhaps Michael should have at least a quick look, too, the state
space (static vs. dynamic features, supported vs. enabled, snapshot time vs.
normal runtime) is a bit mind-boggling, so a 2nd opinion might be good... %-}

[Michael Starzinger, 2013-03-06 16:01:04]

LGTM as well, with one nit.

https://codereview.chromium.org/12391033/diff/10002/src/isolate.cc
File src/isolate.cc (right):

https://codereview.chromium.org/12391033/diff/10002/src/isolate.cc#newcode2159
src/isolate.cc:2159: // Ensure that the stub failure trampoline has been
generated.
The comment is outdated, this ensures that all stubs which need to be generated
ahead of time, but cannot be serialized into the snapshot have been generated.