Bug 160291

Summary: [ARM] REGRESSION(r203786): jit.m_assembler.buffer().codeSize() <= static_cast<size_t>(m_inlineSize)
Product: WebKit Reporter: Csaba Osztrogon√°c <ossy>
Component: JavaScriptCoreAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Critical CC: ggaren, mark.lam, sbarati
Priority: P1    
Version: Other   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 108645, 160110    

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.