114811 2013-04-18 06:40:12 -0700 LLInt ARM backend should not use the d8 register as scratch register 2013-07-22 15:21:10 -0700 1 1 1 Unclassified WebKit JavaScriptCore 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 108645 1 rgabor webkit-unassigned barraclough benjamin commit-queue fpizlo oliver ossy sg5.lee zherczeg oldest_to_newest 877867 0 rgabor 2013-04-18 06:40:12 -0700 LLInt ARM backend is using d8 register as scratch register but the ARM ABI says that d8-d15 registers must be preserved across subroutine calls. 877869 1 198731 rgabor 2013-04-18 06:42:41 -0700 Created attachment 198731 proposed fix 878055 2 benjamin 2013-04-18 13:31:46 -0700 I don't know much about LLInt, but why does the ABI matters at all here? I would think the only thing that matters is follow the JIT conventions(?). 878077 3 fpizlo 2013-04-18 14:12:32 -0700 (In reply to comment #2) > I don't know much about LLInt, but why does the ABI matters at all here? > I would think the only thing that matters is follow the JIT conventions(?). I think that the LLInt uses more scratch registers, and it doesn't have to use the same scratch registers as the JIT. So this change looks valid to me. 878097 4 198731 commit-queue 2013-04-18 14:55:16 -0700 Comment on attachment 198731 proposed fix Clearing flags on attachment: 198731 Committed r148705: <http://trac.webkit.org/changeset/148705> 878098 5 commit-queue 2013-04-18 14:55:18 -0700 All reviewed patches have been landed. Closing bug. 888031 6 sg5.lee 2013-05-12 16:36:24 -0700 Is there any reason to duplicate my preceding bug report and fix (https://bugs.webkit.org/show_bug.cgi?id=114495) as new one? 888035 7 benjamin 2013-05-12 17:11:14 -0700 (In reply to comment #6) > Is there any reason to duplicate my preceding bug report and fix (https://bugs.webkit.org/show_bug.cgi?id=114495) as new one? In WebKit, we care about: -bug report with the best patch. -bug report with the best info. The order in which bugs are reported does not matter. We dupe backward or forward to the best bug report. 888133 8 rgabor 2013-05-13 00:51:19 -0700 (In reply to comment #6) > Is there any reason to duplicate my preceding bug report and fix (https://bugs.webkit.org/show_bug.cgi?id=114495) as new one? Sorry, I forgot to check before I reported and fixed it. I found this bug after debugging a bug for a week. 888155 9 sg5.lee 2013-05-13 02:25:38 -0700 Hello, Benjamin Poulain > In WebKit, we care about: > -bug report with the best patch. > -bug report with the best info. > The order in which bugs are reported does not matter. We dupe backward or > forward to the best bug report. What do you mean by "best patch" or "best info"? Do you mean followings? 1) I didn't make my suggested patch as attached patch. 2) I didn't request to reviewer more aggressively (by using IRC or by sending mail again and again) I cannot find the difference between mine and this one: title(114495-mine): LLInt should not use d8 register as scratch register title(114811-this): LLInt ARM backend should not use the d8 register as scratch register and here is my bug report: Currently, LLInt uses d8 register as scratch register as followings: ARM_SCRATCH_FPR = SpecialRegister.new("d8") in arm.rb C_LOOP_SCRATCH_FPR = SpecialRegister.new("d8") in cloop.rb However, AAPCS §5.1.2.1 says Registers s16-s31 (d8-d15, q4-q7) must be preserved across subroutine calls; registers s0-s15 (d0-d7, q0-q3) do not need to be preserved (and can be used for passing arguments or returning results in standard procedure-call variants). Registers d16-d31 (q8-q15), if present, do not need to be preserved. Therefore it should not use d8 for that purpose. I think it would be safe to use d6. (Register d7 is already in use for other purpose. ) ARM_SCRATCH_FPR = SpecialRegister.new("d6") in arm.rb C_LOOP_SCRATCH_FPR = SpecialRegister.new("d6") in cloop.rb 888170 10 ossy 2013-05-13 03:20:16 -0700 Gábor ran into the same bug and then reported and fixed it quickly. And then apologized to you because he didn't check/find if there was already a bug report about this bug. Additionally it isn't so easy to find it, because there are 15847 unconfirmed/new bugs now. If you file a new bug report without cc-ing/poke-ing folks maybe nobody will notice that you filed a new bug report. 910845 11 mark.lam 2013-07-22 15:21:10 -0700 *** Bug 114495 has been marked as a duplicate of this bug. *** 198731 2013-04-18 06:42:41 -0700 2013-04-18 14:55:15 -0700 proposed fix llint_register.patch text/plain 1348 rgabor SW5kZXg6IFNvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291 cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwkocmV2aXNpb24gMTQ4NjcxKQorKysgU291cmNl L0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE1IEBA CisyMDEzLTA0LTE4ICBHYWJvciBSYXBjc2FueWkgIDxyZ2Fib3JAd2Via2l0Lm9yZz4KKworICAg ICAgICBMTEludCBBUk0gYmFja2VuZCBzaG91bGQgbm90IHVzZSB0aGUgZDggcmVnaXN0ZXIgYXMg c2NyYXRjaCByZWdpc3RlcgorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1 Zy5jZ2k/aWQ9MTE0ODExCisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisK KyAgICAgICAgVGhlIGQ4IHJlZ2lzdGVyIG11c3QgcHJlc2VydmVkIGFjcm9zcyBmdW5jdGlvbiBj YWxscyBhbmQgc2hvdWxkCisgICAgICAgIG5vdCB1c2VkIGFzIHNjcmF0Y2ggcmVnaXN0ZXIuIENo YW5naW5nIGl0IHRvIGQ2LgorCisgICAgICAgICogb2ZmbGluZWFzbS9hcm0ucmI6CisKIDIwMTMt MDQtMTggIEpvbmF0aGFuIExpdSAgPG5ldDE0N0BnbWFpbC5jb20+CiAKICAgICAgICAgSW1wbGVt ZW50IEpJVCBmb3IgTWluR1ctdzY0IDY0LWJpdApJbmRleDogU291cmNlL0phdmFTY3JpcHRDb3Jl L29mZmxpbmVhc20vYXJtLnJiCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9KYXZhU2NyaXB0Q29yZS9v ZmZsaW5lYXNtL2FybS5yYgkocmV2aXNpb24gMTQ4NjU5KQorKysgU291cmNlL0phdmFTY3JpcHRD b3JlL29mZmxpbmVhc20vYXJtLnJiCSh3b3JraW5nIGNvcHkpCkBAIC02NSw3ICs2NSw3IEBAIGVu ZAogCiBBUk1fRVhUUkFfR1BSUyA9IFtTcGVjaWFsUmVnaXN0ZXIubmV3KCJyOSIpLCBTcGVjaWFs UmVnaXN0ZXIubmV3KCJyOCIpLCBTcGVjaWFsUmVnaXN0ZXIubmV3KCJyMyIpXQogQVJNX0VYVFJB X0ZQUlMgPSBbU3BlY2lhbFJlZ2lzdGVyLm5ldygiZDciKV0KLUFSTV9TQ1JBVENIX0ZQUiA9IFNw ZWNpYWxSZWdpc3Rlci5uZXcoImQ4IikKK0FSTV9TQ1JBVENIX0ZQUiA9IFNwZWNpYWxSZWdpc3Rl ci5uZXcoImQ2IikKIAogZGVmIGFybU1vdmVJbW1lZGlhdGUodmFsdWUsIHJlZ2lzdGVyKQogICAg ICMgQ3VycmVudGx5IHdlIG9ubHkgaGFuZGxlIHRoZSBzaW1wbGUgY2FzZXMsIGFuZCBmYWxsIGJh Y2sgdG8gbW92L21vdnQgZm9yIHRoZSBjb21wbGV4IG9uZXMuCg==