PThe previouslys attempt, which made do with a single offset in computeCalleeSaveRegisterPairs, the pass_va test functions were built as CombineSPBump=1,wasn't quite enough. but now this function gets CombineSPBump=0 and a slightly different prologueThe previous attempt only worked as long as CombineSPBump == true (since the offset would be adjusted later in fixupCalleeSaveRestoreStackOffset).
The previous attempt at offsetting the manually stored registers failed when the first callee saved registers are stored with a pre-indexed str with writeback,Instead include the size for the fixed stack area used for win64 varargs in calculations in emitPrologue/emitEpilogue. like pass_va is built now. This attempt seems much less hacky.The stack
consists of mainly three parts;
---The latter two are often used together (for the offset from the original stack position, to the start of the local stack area) and are summed up in the CSStackSize variable. (Reviewer question: Should we keep it this way, or keep CSStackSize as is, and create a new variable for the sum, such as RegDumpSize?)
I've got a pretty big function that I can try to make a test out from - now all callee saved registers are stored in the exact same spot as they are described to reside in in the MIRn addition to moving the offsetting into emitPrologue/emitEpilogue which fixes functions with CombineSPBump == false), also set the frame pointer to point to the right location, where the frame pointer and link register actually are stored. In addition to the prologue/epilogue, this also requires changes to resolveFrameIndexReference.
I haven't triggered codepaths with HasFP=1 in tests yet - any suggestions on tests that would do that,Add tests for a function that keeps a frame pointer and that uses a VLA.
Outside of the tests in the testsuite, I've now tested this with a large array of different vararg function variants, including VLAs, both targeting win64 and when using the win64 calling convention on linux. or any other combinations that I should test as well?For linux, I've gotten it pretty well tested in a rather big codebase in practice now at least.also tested to make sure that C++ exceptions can be properly passed through a win64cc vararg function and checked that the produced .cfi directives look correct.