https://bugs.kde.org/show_bug.cgi?id=523843
--- Comment #15 from Martin Cermak <[email protected]> --- Created attachment 196347 --> https://bugs.kde.org/attachment.cgi?id=196347&action=edit proposed patch (In reply to Mark Wielaard from comment #14) [ ... stuff deleted ... ] > So this is the only thing we seem to disagree on. > My claim is that it is NOT equivalent to the alignment check, which does > more work (precisely because it is a sanity check, so it double checks > everything). > > Since we know on the host in doHelperCall how big argbytes is we > can avoid the addition/subtraction dance in the guest if it already > is a multiple of 16 bytes. In that case the only thing we need to do > in the guest is adjusting SP to make sure it is 16 bytes aligned. > > Which is why I suggesting we do the following: > > HReg tmp = newVRegI(env); > addInstr(env, mk_iMOVsd_RR(hregX86_ESP(), tmp)); > if ( argbytes % 16 != 0) > addInstr(env, X86Instr_Alu32R(Xalu_SUB, X86RMI_Imm(argbytes), tmp)); > addInstr(env, X86Instr_Alu32R(Xalu_AND, X86RMI_Imm(0xfffffff0), tmp)); > if ( argbytes % 16 != 0) > addInstr(env, X86Instr_Alu32R(Xalu_ADD, X86RMI_Imm(argbytes), tmp)); > addInstr(env, mk_iMOVsd_RR(tmp, hregX86_ESP())); > > So we do what you suggest, add argbytes to esp, mask to 16 bytes, subtract > argbytes. > But if we know argbytes is a multiple of 16 we just mask esp to 16 bytes. It makes perfect sense to me now. Thank you for your patient explanation. If we know that pushing args onto the stack won't cause further misalignment per se, we can only focus on making sure the "incoming" SP is aligned. I'm attaching the modified path and also pushing the update to my topic branch users/mcermak/try-bug523843-stack-alignment so that it gets additional buildbot testing before I'll hopefully check it in on Monday :) -- You are receiving this mail because: You are watching all bug changes.
