https://trac.webkit.org/changeset/203786 changed the IC code and made zillion tests assert/crash again. :( Before r203786, almost all tests passed with the patch in https://bugs.webkit.org/show_bug.cgi?id=159720 . But after r203786 I got the following assert: ASSERTION FAILED: jit.m_assembler.buffer().codeSize() <= static_cast<size_t>(m_inlineSize) ../../Source/JavaScriptCore/jit/JITMathIC.h(135) : JSC::JITMathIC<Generator>::generateOutOfLine(JSC::VM&, JSC::CodeBlock*, JSC::FunctionPtr)::<lambda()> [with GeneratorType = JSC::JITAddGenerator] 1 0xb64318e0 WTFCrash 2 0xb5f3efb8 JSC::JITMathIC<JSC::JITAddGenerator>::generateOutOfLine(JSC::VM&, JSC::CodeBlock*, JSC::FunctionPtr)::{lambda()#1}::operator()() const 3 0xb5f3f438 JSC::JITMathIC<JSC::JITAddGenerator>::generateOutOfLine(JSC::VM&, JSC::CodeBlock*, JSC::FunctionPtr) 4 0xb5f35d1c Segmentation fault --- jit.m_assembler.buffer().codeSize() = 12 static_cast<size_t>(m_inlineSize) = 4 Could you give me some hint what changed here? Why isn't there enough space to use ldr + b + immediate (12 bytes) for jump? Could you share me how long will you work refactoring this IC thing? I won't have time to fix new and new regressions every day. Maybe I simply let ARMAssembler completely broken until you finish this development, and then try to debug all regression. Maybe let it broken forever, who knows.
I think this is covered by your other work arounds. Do you agree? I think this all comes down to the arm assembler predictably patching over code with similar code of the same size. I'm not sure what's involved in the constant pool flushing work to make this all work. It's possible for now, as I commented in your other bug, to have traditional arm assembler just fall back to old Math behavior for add/mul/etc.