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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
