While working on the matching work, I started wondering whether the var_order pragma, and the whole C1XX.DLL shim it depends on, is strictly necessary, or whether the same stack ordering could be achieved without patching the compiler front-end.
As far as I can tell the hack works by reordering entries in C1XX's local-scope symbol table so that the hash-bucket iteration order, which is ultimately what drives stack slot allocation, comes out in the requested sequence. The thing is, that shuffling is only needed because everything lives in one flat function scope.
If you instead split the variables into explicit nested { } block scopes, CL.EXE's allocation becomes essentially deterministic per scope, and the ordering falls out of the source structure itself, no pragma required.
So far I've reproduced the exact layouts the pragma was producing, without the pragma, for all but a handful of exceptions. I'm still working through those remaining cases. Dropping the wrapper would also simplify setup quite a bit (no renaming C1XX.DLL, no separate build step). Opening this to track it and to check whether the approach has already been explored or ruled out.
While working on the matching work, I started wondering whether the var_order pragma, and the whole C1XX.DLL shim it depends on, is strictly necessary, or whether the same stack ordering could be achieved without patching the compiler front-end.
As far as I can tell the hack works by reordering entries in C1XX's local-scope symbol table so that the hash-bucket iteration order, which is ultimately what drives stack slot allocation, comes out in the requested sequence. The thing is, that shuffling is only needed because everything lives in one flat function scope.
If you instead split the variables into explicit nested { } block scopes, CL.EXE's allocation becomes essentially deterministic per scope, and the ordering falls out of the source structure itself, no pragma required.
So far I've reproduced the exact layouts the pragma was producing, without the pragma, for all but a handful of exceptions. I'm still working through those remaining cases. Dropping the wrapper would also simplify setup quite a bit (no renaming C1XX.DLL, no separate build step). Opening this to track it and to check whether the approach has already been explored or ruled out.