Closed Bug 918206 Opened 6 years ago Closed 6 years ago

ARM: FP register out of range when patching constant pool reference.

Categories

(Core :: JavaScript Engine, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla27

People

(Reporter: dougc, Assigned: jonco)

References

Details

Attachments

(1 file, 1 obsolete file)

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.
Assignee: general → jcoppeard
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.
Attachment #807090 - Attachment is obsolete: true
Attachment #807189 - Flags: review?(mrosenberg)
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.
Attachment #807189 - Flags: review?(mrosenberg) → review+
(In reply to Marty Rosenberg [:mjrosenb] from comment #4)

Nope, it was my bad from the float32 support :)
https://hg.mozilla.org/mozilla-central/rev/a8ba4fdc133f
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
You need to log in before you can comment on or make changes to this bug.