Hi everyone,

Now that I'm back in my element and looking for improvements in the generated assembly language, I'm pondering about refactoring something in the Peephole Optimizer when it comes to removing instrucitons.

During the development of the optimisations over at #37389, I was struggling to deal with an internal error that was cropping up for no apparent reason, and the reason for that is because I forgot to call "asml.remove" on an instruction before freeing it, therefore causing a dangling pointer to remain in the linked list.  To avoid this situation from happening in the future, I would like to introduce a new method called RemoveInstruction that ensures that the instruction is removed from AsmL before being freed.  While RemoveCurrentP already exists, it is designed only for the current instruction and not ones that appear later, especially if the instruction that appears after it is unknown.

For a more experimental one, I want to see if it's possible to run the Peephole Optimizer (with the possible exception of the Post-Peephole stage due to the nature of its optimisations) before all the virtual registers are turned to real ones, because a number of optimisations involve the removal of registers holding temporary values and hence might allow a simpler function prologue and epilogue to be generated.  Also, some potential new optimisations would require rearranging registers, an overly complex task that can be avoided completely if virtual registers are used.  Theoretically, the only changes that would be needed is to ensure the TUsedRegs objects can handle virtual registers (trying to use it now will cause an out of bounds error or access violation on account of the virtual registers having starting indices of 2^24).

Gareth aka. Kit

So I'm now running the full test suite, including "make fullcycle" for my refactoring of instruction removal (replacing most references of "asml.remove(hp1); hp1.free;" etc. with "RemoveInstruction(hp1);".  Trying to get the optimiser to run before assigning real registers to the instructions is actually somewhat difficult.  Besides having to avoid certain optimisations like CMOV that don't allow writing to the stack (although this is under pass 2, which helps), removal of instructions can sometimes result in danglong pointers for the "livestart" and "liveend" fields for the register tracking.

I'll submit the 'removal refactor' patch once everything has passed, this helps reduce maintenance and avoids dangling pointers (i.e. forgetting to call "asml.remove" before freeing an instruction), but running pass 1 of the peephole optimizer before assigning registers is still very much experimental and may be too complicated.  I'll also have to look at the effects on compiler speed and the quality of the binaries produced to see if it's truly worthwhile.

Gareth aka. Kit

https://bugs.freepascal.org/view.php?id=37399 - made the refactor patch and tested it on i386-win32 and x86_64-win64, as well as cross compilation with "make fullcycle" to catch the most blatant of errors.  It will require testing on other platforms though.

Gareth aka. Kit