https://trac.webkit.org/changeset/218869 (bug173700) broke the AArch64 build: https://build.webkit.org/builders/JSCOnly%20Linux%20AArch64%20Release/builds/1126 {standard input}: Assembler messages: {standard input}:28: Error: unexpected register in the immediate operand at operand 3 -- `subs xzr,x3,sp' {standard input}:120: Error: unexpected register in the immediate operand at operand 3 -- `subs xzr,x3,sp' note: I just noticed this build failure, no time and plan to fix it myself.
I'll take a look.
Yeah on ARM64 that second register can't be SP, because register 31 means ZR here.
I think we want this: diff --git a/Source/JavaScriptCore/llint/LowLevelInterpreter64.asm b/Source/JavaScriptCore/llint/LowLevelInterpreter64.asm index fd35381d..0fb0254 100644 --- a/Source/JavaScriptCore/llint/LowLevelInterpreter64.asm +++ b/Source/JavaScriptCore/llint/LowLevelInterpreter64.asm @@ -136,7 +136,7 @@ macro doVMEntry(makeCall) addp CallFrameHeaderSlots, t4, t4 lshiftp 3, t4 subp sp, t4, t3 - bpa t3, sp, .throwStackOverflow + bibeq sp, t3, .throwStackOverflow # Ensure that we have enough additional stack capacity for the incoming args, # and the frame for the JS code we're executing. We need to do this check It still makes the assembler sad though. I think it expects "wsp" and is sad when it just sees "sp"? Looking...
Ugh this is weird. arm64.rb:arm64Operand can't return "wsp" for "sp" all the time because other instructions get sad. But manually editing DerivedSources/JavaScriptCore/LLIntAssembly.h to "wsp" in those two spots works. So I can hack up arm64.rb:lowerARM64's handing for these branch instructions...
Oh derp, the problem is we're using w registers instead of x. This should be 64-bit, not 32, and the "sp" is implicitly 64 so no need for "xsp". Why is are we doing that though? Looking more...
OK bqbeq is the right thing, since it's quad. I now know a bit more llint.
Created attachment 314032 [details] patch
Another option is to teach all the branches to flip their operands and the condition if the last operand is SP. I'm not sure that's worth doing in this patch.
Comment on attachment 314032 [details] patch this works as a workaround but bpa should also work because p stands for ointer and pointer on 64bit should be quad
The patch got reverted, I'll re-apply it with this fix.
Will fix in 173700. *** This bug has been marked as a duplicate of bug 173700 ***