RESOLVED FIXED Bug 170672
[aarch64][Linux] m_allowScratchRegister assert hit in MacroAssemblerARM64 under B3::Air::CCallSpecial::generate()
https://bugs.webkit.org/show_bug.cgi?id=170672
Summary [aarch64][Linux] m_allowScratchRegister assert hit in MacroAssemblerARM64 und...
Zan Dobersek
Reported 2017-04-10 05:09:32 PDT
[aarch64][Linux] m_allowScratchRegister assert hit in MacroAssembler64 under B3::Air::CCallSpecial::generate()
Attachments
Patch (1.85 KB, patch)
2017-04-10 05:24 PDT, Zan Dobersek
no flags
Verbose compilation output of a failing stress test (189.40 KB, text/plain)
2017-04-25 04:58 PDT, Zan Dobersek
no flags
Patch (4.38 KB, patch)
2017-05-01 05:56 PDT, Zan Dobersek
no flags
Patch (4.38 KB, patch)
2017-05-01 06:06 PDT, Zan Dobersek
no flags
Archive of layout-test-results from ews112 for mac-elcapitan (1.77 MB, application/zip)
2017-05-01 13:35 PDT, Build Bot
no flags
Zan Dobersek
Comment 1 2017-04-10 05:24:30 PDT
Yusuke Suzuki
Comment 2 2017-04-10 19:55:23 PDT
Comment on attachment 306686 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=306686&action=review Nice, r=me with comment. > Source/JavaScriptCore/b3/air/AirCCallSpecial.cpp:137 > + jit.call(scratchRegister); Could you add a test to testair to ensure that the bug is fixed?
Yusuke Suzuki
Comment 3 2017-04-10 20:20:06 PDT
Comment on attachment 306686 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=306686&action=review >> Source/JavaScriptCore/b3/air/AirCCallSpecial.cpp:137 >> + jit.call(scratchRegister); > > Could you add a test to testair to ensure that the bug is fixed? And I think it is not necessary for x86. Please add `isX86()` guard.
Zan Dobersek
Comment 4 2017-04-16 13:35:34 PDT
(In reply to Yusuke Suzuki from comment #2) > Comment on attachment 306686 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=306686&action=review > > Nice, r=me with comment. > > > Source/JavaScriptCore/b3/air/AirCCallSpecial.cpp:137 > > + jit.call(scratchRegister); > > Could you add a test to testair to ensure that the bug is fixed? I'm having some issues constructing the test in testair. As far as I understand a valid B3::CCallValue object is necessary when generating the Patch instruction that uses the problematic CCallSpecial. That requires including a bunch of B3 classes into testair.cpp, which I'm not certain is acceptable. Testing this in testb3 might also be difficult because the problem manifests when using an optimization level lower than the default (2).
Saam Barati
Comment 5 2017-04-17 13:19:16 PDT
(In reply to Zan Dobersek from comment #4) > (In reply to Yusuke Suzuki from comment #2) > > Comment on attachment 306686 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=306686&action=review > > > > Nice, r=me with comment. > > > > > Source/JavaScriptCore/b3/air/AirCCallSpecial.cpp:137 > > > + jit.call(scratchRegister); > > > > Could you add a test to testair to ensure that the bug is fixed? > > I'm having some issues constructing the test in testair. As far as I > understand a valid B3::CCallValue object is necessary when generating the > Patch instruction that uses the problematic CCallSpecial. That requires > including a bunch of B3 classes into testair.cpp, which I'm not certain is > acceptable. > > Testing this in testb3 might also be difficult because the problem manifests > when using an optimization level lower than the default (2). I think you should test it in testb3 and then just manually set the optimization level on the procedure you create.
Saam Barati
Comment 6 2017-04-24 12:54:12 PDT
Any luck writing a test, Zan?
Zan Dobersek
Comment 7 2017-04-25 04:29:56 PDT
(In reply to Saam Barati from comment #6) > Any luck writing a test, Zan? No. I'm able to write out a minimized B3 procedure that ends up generating a CCall instruction in Air, but I can't determine what gets the callee argument generated in the address form in the stress tests so that I could reproduce that in the B3 test case.
Zan Dobersek
Comment 8 2017-04-25 04:58:14 PDT
Created attachment 308092 [details] Verbose compilation output of a failing stress test Here's the verbose compilation output for one failing stress test. Right before the Air generation, there are two problematic patchpoints that use the callee in address form, in BB#10 and BB#22. If anyone wants to take this over, feel free to do so.
Zan Dobersek
Comment 9 2017-05-01 05:38:38 PDT
The problem turned out to be a combination of linear scan usage (enabled when optimization level is lowered below 2) and the callee argument of a Air::CCallSpecial being spilt on the stack.
Zan Dobersek
Comment 10 2017-05-01 05:56:31 PDT
Build Bot
Comment 11 2017-05-01 05:58:17 PDT
Attachment 308715 [details] did not pass style-queue: ERROR: Source/JavaScriptCore/b3/testb3.cpp:10456: Consider using CHECK_EQ instead of CHECK(a == b) [readability/check] [2] Total errors found: 1 in 3 files If any of these errors are false positives, please file a bug against check-webkit-style.
Zan Dobersek
Comment 12 2017-05-01 06:06:23 PDT
Zan Dobersek
Comment 13 2017-05-01 06:07:16 PDT
(In reply to Zan Dobersek from comment #12) > Created attachment 308716 [details] > Patch This takes a different approach, disallowing spilling the callee argument on the stack for ARM64. I'm not sure this is preferable to special-casing for the Arg::Addr callee in generate() (as proposed in comment #3) -- input welcome.
Saam Barati
Comment 14 2017-05-01 10:23:45 PDT
(In reply to Zan Dobersek from comment #13) > (In reply to Zan Dobersek from comment #12) > > Created attachment 308716 [details] > > Patch > > This takes a different approach, disallowing spilling the callee argument on > the stack for ARM64. I'm not sure this is preferable to special-casing for > the Arg::Addr callee in generate() (as proposed in comment #3) -- input > welcome. Why doesn't this effect x86? Can it encode calls to arbitrary addresses?
Saam Barati
Comment 15 2017-05-01 10:24:14 PDT
Fil, Michael, any thoughts?
Filip Pizlo
Comment 16 2017-05-01 10:26:17 PDT
(In reply to Saam Barati from comment #14) > (In reply to Zan Dobersek from comment #13) > > (In reply to Zan Dobersek from comment #12) > > > Created attachment 308716 [details] > > > Patch > > > > This takes a different approach, disallowing spilling the callee argument on > > the stack for ARM64. I'm not sure this is preferable to special-casing for > > the Arg::Addr callee in generate() (as proposed in comment #3) -- input > > welcome. > > Why doesn't this effect x86? Can it encode calls to arbitrary addresses? Yes.
Build Bot
Comment 17 2017-05-01 13:35:05 PDT
Comment on attachment 308716 [details] Patch Attachment 308716 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/3653003 New failing tests: fast/dom/Window/slow-unload-handler-overwritten-date.html
Build Bot
Comment 18 2017-05-01 13:35:07 PDT
Created attachment 308759 [details] Archive of layout-test-results from ews112 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews112 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Zan Dobersek
Comment 19 2017-05-01 21:32:11 PDT
Comment on attachment 308716 [details] Patch Clearing flags on attachment: 308716 Committed r216058: <http://trac.webkit.org/changeset/216058>
Zan Dobersek
Comment 20 2017-05-01 21:32:15 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.