Bug 160291 - [ARM] REGRESSION(r203786): jit.m_assembler.buffer().codeSize() <= static_cast<size_t>(m_inlineSize)
Summary: [ARM] REGRESSION(r203786): jit.m_assembler.buffer().codeSize() <= static_cast...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P1 Critical
Assignee: Nobody
Depends on:
Blocks: 108645 160110
  Show dependency treegraph
Reported: 2016-07-28 04:57 PDT by Csaba Osztrogonác
Modified: 2016-07-31 14:09 PDT (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Csaba Osztrogonác 2016-07-28 04:57:35 PDT
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.
Comment 1 Saam Barati 2016-07-31 14:09:10 PDT
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.