WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
160291
[ARM] REGRESSION(
r203786
): jit.m_assembler.buffer().codeSize() <= static_cast<size_t>(m_inlineSize)
https://bugs.webkit.org/show_bug.cgi?id=160291
Summary
[ARM] REGRESSION(r203786): jit.m_assembler.buffer().codeSize() <= static_cast...
Csaba Osztrogonác
Reported
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.
Attachments
Add attachment
proposed patch, testcase, etc.
Saam Barati
Comment 1
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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug