Merged r16772, r18000, r18298, r18319 into 3.21 branch.

Merged r16772, r18000, r18298, r18319 into 3.21 branch.

Add a mechanism to override the detected cpu features.

Restore saved caller FP registers on stub failure and preserve FP registers on NotifyStubFailure.

Initialize Date parse cache with SMI instead of double to workaround sharing mutable heap numbers in snapshot.

Fix NotifyStubFailureSaveDoubles generation for ia32.

BUG=280531
LOG=N
R=svenpanne@chromium.org

[Sven Panne, 2014-01-10 14:06:42]

LGTM (rubberstamped)

[ulan, 2014-01-10 15:28:35]

Hi Paul,

I am merging this CL to 3.21. It fails in mipsel.release.check in many tests. It
doesn't fail in debug mode though.

Could you please take a look? Maybe I missed something in the CL or there is a
known MIPS issue?

Stacktrace from a failure:

#0  0x080f0ce4 in v8::internal::StackFrameIterator::Advance() ()
#1  0x081eed51 in
v8::internal::MarkCompactCollector::PrepareThreadForCodeFlushing(v8::internal::Isolate*,
v8::internal::ThreadLocalTop*) ()
#2  0x081eeee8 in v8::internal::MarkCompactCollector::PrepareForCodeFlushing()
()
#3  0x081ef166 in v8::internal::MarkCompactCollector::MarkLiveObjects() ()
#4  0x081f2dc0 in v8::internal::MarkCompactCollector::CollectGarbage() ()
#5  0x08127d6a in
v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector,
v8::internal::GCTracer*) [clone .constprop.637] ()
#6  0x0812821c in
v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace,
v8::internal::GarbageCollector, char const*, char const*) ()
#7  0x081287bd in v8::internal::Heap::CollectAllGarbage(int, char const*) ()
#8  0x080d5222 in
v8::internal::GCExtension::GC(v8::FunctionCallbackInfo<v8::Value> const&) ()
#9  0x083bc0d8 in v8::internal::FunctionCallbackArguments::Call(void
(*)(v8::FunctionCallbackInfo<v8::Value> const&)) ()
#10 0x0809276e in v8::internal::Builtin_HandleApiCall(int,
v8::internal::Object**, v8::internal::Isolate*) ()
#11 0x083a7892 in
v8::internal::Simulator::SoftwareInterrupt(v8::internal::Instruction*) ()
#12 0x083a927f in
v8::internal::Simulator::DecodeTypeRegister(v8::internal::Instruction*) ()
#13 0x083a5fe4 in
v8::internal::Simulator::InstructionDecode(v8::internal::Instruction*) ()
#14 0x083a9c43 in v8::internal::Simulator::CallInternal(unsigned char*) ()
#15 0x083a9cc1 in v8::internal::Simulator::Call(unsigned char*, int, ...) ()
#16 0x080d178d in v8::internal::Invoke(bool,
v8::internal::Handle<v8::internal::JSFunction>, v8::intern

[Paul Lind, 2014-01-10 16:37:14]

Ulan, the fix for this is r18030, which fixes a MIPS-specific code-aging bug.

However, it will not back-merge cleanly to 3.21 branch. I pushed a clean version
(ready to merge) to this github branch:
https://github.com/paul99/v8m-rb/commits/3.21-code-age-fix 

The specific commit is
https://github.com/paul99/v8m-rb/commit/7aab271986921d3262d58abb3c42523db801c141

I will also send you a patch of the same code via email, in case that is easier.

This bug surfaced only when the code-aging sequence was right at a 64K boundary
in generated code, so when a release build hit the boundary, the corresponding
debug build (more code emitted) would not.

[Paul Lind, 2014-01-13 02:10:46]

If you don't want to merge in 18030 and deal with the conflicts, we can ask Ákos
to separately do it separately once this CL lands. I've cc'd him here.

We should have previously back-merged this to the branches. We will do so to
3.22 and 3.20 (Android webview still uses 3.20), once this one is resolved.

[ulan, 2014-01-13 08:32:54]

On 2014/01/13 02:10:46, Paul Lind wrote:
> If you don't want to merge in 18030 and deal with the conflicts, we can ask
Ákos
> to separately do it separately once this CL lands. I've cc'd him here.
> 

Thanks for looking into this, Paul! I am going to merge r16772, r18000, r18298,
r18319 + your uploaded patch of 18030 in a new CL.

> We should have previously back-merged this to the branches. We will do so to
> 3.22 and 3.20 (Android webview still uses 3.20), once this one is resolved.
I will merge r16772, r18000, r18298, r18319 to 3.20 too. Would you like me to
include your patch of 18030 in the merge? Or should I wait until you merge it to
3.20?

[ulan, 2014-01-13 09:21:37]

Abandoning this CL for https://codereview.chromium.org/132193005

[ulan, 2014-01-13 10:12:19]

> Would you like me to include your patch of 18030 in the merge? Or should I
wait until you merge it to 3.20?
The 18030 patch adapted for 3.21 also applies cleanly in 3.20. So I'll go ahead
and merge it with r16772, r18000, r18298, r18319 to 3.20.

[Paul Lind, 2014-01-13 17:40:24]

On 2014/01/13 10:12:19, ulan wrote:
> The 18030 patch adapted for 3.21 also applies cleanly in 3.20. So I'll go
ahead
> and merge it with r16772, r18000, r18298, r18319 to 3.20.
Thanks for taking care of the merges on both these branches, Ulan. I really
appreciate! (Sorry for late reply, it was middle of night here....)