JSCOnly build seems to be broken currently (for ARMv7 and MIPS32el). From https://build.webkit.org/builders/JSCOnly%20Linux%20ARMv7%20Thumb2%20Release/builds/10050: FAILED: Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/dfg/DFGSpeculativeJIT.cpp.o /home/buildbot/buildroot/buildroot/output.rpi3/host/usr/ccache/arm-buildroot-linux-gnueabihf-g++ ... -c ../../Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp: In member function ‘void JSC::DFG::SpeculativeJIT::compileIncOrDec(JSC::DFG::Node*)’: ../../Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:4625:37: error: no matching function for call to ‘JSC::DFG::SpeculativeJIT::jsValueResult(JSC::GPRReg, JSC::DFG::Node*&)’ jsValueResult(result.gpr(), node);
Seems to be broken between r252678 and r252682. JSCOnly Linux MIPS32el Release: failed on: r252685 https://build.webkit.org/builders/JSCOnly%20Linux%20MIPS32el%20Release/builds/4021 passed on: r252678 https://build.webkit.org/builders/JSCOnly%20Linux%20MIPS32el%20Release/builds/4020 JSCOnly Linux ARMv7 Thumb2 Release failed on: r252682 https://build.webkit.org/builders/JSCOnly%20Linux%20ARMv7%20Thumb2%20Release/builds/10050 passed on: r252670 https://build.webkit.org/builders/JSCOnly%20Linux%20ARMv7%20Thumb2%20Release/builds/10049
Almost certainly https://trac.webkit.org/changeset/252680/webkit That commit modified DFGSpeculativeJIT.cpp. More specifically it added jsValueResult() call inside SpeculativeJIT(). The landed patch wasn't run through EWS, and EWS had few complaints about previous patches in that bug (e.g.: JSC EWS complained about failing JSC tests). Unfortunately JSCOnly EWS from 'old EWS' wasn't run on this patch as this queue was behind.
There are 2 Patches that broke builds https://trac.webkit.org/changeset/252684 and https://trac.webkit.org/changeset/252680 The fix to https://trac.webkit.org/changeset/252680 is trivial, but I'm working on a proper fix to https://trac.webkit.org/changeset/252684 in https://bugs.webkit.org/show_bug.cgi?id=204082. I'll try to fix both issues there. If it takes longer than expected, I'll create a patch to fix it ASAP.
Created attachment 383955 [details] Patch It fixes the build issues, but it won't have desired behavior until we fix https://bugs.webkit.org/show_bug.cgi?id=204082
(In reply to Caio Lima from comment #4) > Created attachment 383955 [details] > Patch > > It fixes the build issues, but it won't have desired behavior until we fix > https://bugs.webkit.org/show_bug.cgi?id=204082 I uploaded the wrong diff.
Created attachment 383956 [details] Patch
rs=me
Created attachment 383963 [details] Patch
Comment on attachment 383963 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=383963&action=review r=me. I’ll let you decide if you want to wait on having the baseline use the IC. > Source/JavaScriptCore/bytecode/AccessCase.cpp:1154 > + jit.loadValue(CCallHelpers::BaseIndex(scratchGPR, scratch2GPR, CCallHelpers::TimesEight), JSValueRegs::payloadOnly(scratchGPR)); This won’t work for 32-bit. Is the goal just to get it to compile? > Source/JavaScriptCore/jit/JITPropertyAccess32_64.cpp:-149 > - callOperation(operationGetByVal, dst, m_codeBlock->globalObject(), JSValueRegs(regT1, regT0), JSValueRegs(regT3, regT2)); Why not wait to do this until it all works?
Comment on attachment 383963 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=383963&action=review Thank you very much for the review! >> Source/JavaScriptCore/bytecode/AccessCase.cpp:1154 >> + jit.loadValue(CCallHelpers::BaseIndex(scratchGPR, scratch2GPR, CCallHelpers::TimesEight), JSValueRegs::payloadOnly(scratchGPR)); > > This won’t work for 32-bit. Is the goal just to get it to compile? Yes. I already fixed it to 32-bit locally on GetByVal IC changes. >> Source/JavaScriptCore/jit/JITPropertyAccess32_64.cpp:-149 >> - callOperation(operationGetByVal, dst, m_codeBlock->globalObject(), JSValueRegs(regT1, regT0), JSValueRegs(regT3, regT2)); > > Why not wait to do this until it all works? This also caused a compilation error, since it requires we move `operationGetByVal` out of "DFGOperations.h" or include this header in this file. I think that falling back to slowpath always is a better solution to make it compile.
Comment on attachment 383963 [details] Patch Clearing flags on attachment: 383963 Committed r252690: <https://trac.webkit.org/changeset/252690>
All reviewed patches have been landed. Closing bug.
<rdar://problem/57362597>