If I add a new patch to the compiler speed pack, I need to know if the compiler still does the same (but faster). The first indication that I broke something is, that the compiler throws an access violation. The second indication is if the compiler finished, but the lines of code, code size or data size doesn’t match the original compiler’s values. But even that doesn’t guarantee that it isn’t broken. The next step is to call the original and the patched function and compare their results and modified data for every call. But sometime there is just too much modified data or I don’t know what data was modified. So calling both functions in one compiler run doesn’t work. In that case I need to write the results to a file and compare the data with the next compiler run. For this I use a very large project and rebuild it completely, including the RTL, VCL, components and project units. This covers a lot of cases and some corner cases. After that I can’t do more because I can’t unit-test the compiler.
Unfortunately RAD Studio 10 Seattle has a problem with the Win64 compiler. The compiler’s output of the code and data size always changes. That is without the compiler speed pack, just the original DCC64.EXE that was installed by the RAD Studio Installer. This makes it impossible for me to verify that I didn’t break the compiler with my patches.
After some research I must say that the 10 Seattle’s Win64 compiler’s generated code isn’t deterministic anymore (same input doesn’t generate the same output). It’s like the compiler uses the Random function to allocate CPU registers, so it could be an uninitialized variable somewhere in the compiler. The Win32 compiler and the XE8 and older Win64 compilers aren’t affected by this. So this is a regression bug for 10 Seattle.