This one looks like it might be caused by the float32 changes just need to scrutinize the paths to keep the codes consistent. #0 js::jit::FloatRegister::FromCode (i=16) at js/src/jit/Registers.h:61 #1 0x74921d2c in PoolHintData::getVFPReg (this=0x69f95080) at js/src/jit/arm/Assembler-arm.cpp:1629 #2 0x7491ce6e in js::jit::Assembler::patchConstantPoolLoad (loadAddr=0x80c276ec, constPoolAddr=0x80c27354) at js/src/jit/arm/Assembler-arm.cpp:1822 #3 0x74924554 in js::jit::AssemblerBufferWithConstantPool<1024, 4, js::jit::Instruction, js::jit::Assembler, 1>::finishPool (this=0x80374234) at js/src/jit/shared/IonAssemblerBufferWithConstantPools.h:752 #4 0x74922540 in js::jit::AssemblerBufferWithConstantPool<1024, 4, js::jit::Instruction, js::jit::Assembler, 1>::flushPool (this=0x80374234) at js/src/jit/shared/IonAssemblerBufferWithConstantPools.h:950 #5 0x7491e55c in js::jit::Assembler::dumpPool (this=0x80374038) at js/src/jit/arm/Assembler-arm.cpp:2393 #6 0x74928756 in js::jit::CodeGeneratorARM::generateEpilogue (this=0x80374000) at js/src/jit/arm/CodeGenerator-arm.cpp:72 #7 0x74a9a17c in js::jit::CodeGenerator::generate (this=0x80374000) at js/src/jit/CodeGenerator.cpp:5599 #8 0x747fe254 in js::jit::GenerateCode (mir=0x76ef2078, lir=0x804625d0, maybeMasm=0x0) at js/src/jit/Ion.cpp:1498 #9 0x747fe2b4 in js::jit::CompileBackEnd (mir=0x76ef2078, maybeMasm=0x0) at js/src/jit/Ion.cpp:1517 #10 0x747fe926 in js::jit::IonCompile (cx=0x7e0e97a0, script=0x7a8a1500, baselineFrame=0x69f95c48, osrPc=0x0, constructing=false, executionMode=js::jit::SequentialExecution) at js/src/jit/Ion.cpp:1685 #11 0x747fefdc in js::jit::Compile (cx=0x7e0e97a0, script=..., osrFrame=0x69f95c48, osrPc=0x0, constructing=false, executionMode=js::jit::SequentialExecution) at js/src/jit/Ion.cpp:1843 #12 0x747ff7c4 in js::jit::CompileFunctionForBaseline (cx=0x7e0e97a0, script=..., frame=0x69f95c48, isConstructing=false) at js/src/jit/Ion.cpp:2003 #13 0x747ba47e in js::jit::EnsureCanEnterIon (cx=0x7e0e97a0, stub=0x7ec52110, frame=0x69f95c48, script=..., pc=0x7ee39949 "\232", jitcodePtr=0x69f95bd4) at js/src/jit/BaselineIC.cpp:735 #14 0x747ba9d4 in js::jit::DoUseCountFallback (cx=0x7e0e97a0, stub=0x7ec52110, frame=0x69f95c48, infoPtr=0x69f95c34) at js/src/jit/BaselineIC.cpp:918

In getVFPReg, shift the destReg down for a Single before mapping to a FloatRegister, and then in VFPRegister(FloatRegister, RegType) shift it back up for a Single.

(In reply to Douglas Crosher [:dougc] from comment #1) Oh I just started look at this as well. Rather than shifting you can call singleOverlay() / doubleOverlay() to do this for you.

FloatRegister essentially represents a double precision register, so don't use it to represent one of the single precision registers. Instead, for represent single precision registers in PoolHintData by the double register it is an overlay of. We will need to do something else if we want to start using all the single precision registers.

Comment on attachment 807189 [details] [diff] [review] fp-register-out-of-range Review of attachment 807189 [details] [diff] [review]: ----------------------------------------------------------------- whoops. that totally looks like my bug.

(In reply to Marty Rosenberg [:mjrosenb] from comment #4) Nope, it was my bad from the float32 support :)